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PREFACE 


This book is written for systems designers and operating system designers and programmers who plan 
to use the Intel iAPX 286 microprocessor in its protected, virtual-address mode. The protected-mode 
iAPX 286 is designed for multitasking ye systems that serve any users Or that eumitaneausly 
run several programs. 


This book analyzes operating system functions that are appropriate for the iAPX 286 when used in a 
variety of multitasking applications, including 7 , 

¢ Communications, such as automated PBXs 

e Real-time, such as instrumentation or process control 

e Miulti-user, such as time-sharing or office systems 


Many of the features of the iAPX 286 are intended for use by an operating system. This book identifies 
and explains those features and gives examples of how they can be used in an operating system. _ 


AUDIENCE 


This book assumes that you have a knowledge of multitasking operating systems at least equivalent to 
that presented in introductory undergraduate textbooks on the subject. It also assumes that you have 
had some exposure to the architecture of the iAPX 286 through attending an introductory course or 
reading introductory literature such as Introduction to the iAPX 286. 


RELATED PUBLICATIONS 


Intel Literature 


The following manuals contain additional information of use to ) operating-system designers and 
programmers: | , 


© ASM286 Assembly Language Reference Manual, 121924 

° Component Data Catalog, 210298 

© iAPX 286 Architecture Extension Kernel (K286) User’s Giie 121961 
© iAPX 286 Programmer's Reference Manual, 210498 

© iAPX 286 System Builder User’s Guide, 121935 

© iAPX 286 Utilities User’s Guide, 121934 


e iAPX 286/10 High Performance Mi sek acai with ig) Managemen and Erarecyon (Data 
Sheet), 210253 | 


e Introduction to the i:APX 286, 210308 
° PL/M-286 User’s Guide, 121945 
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External Literature 


Many aspects of operating system construction for the iAPX 286 are the same as for other processors. 
The following are sources of generally applicable theories and algorithms referred to in the text of this 
book. 


° ~ Coffman, E.G., Jr., and Peter J. Denning, Operating Systems Theory (Englewood Cliffs, NI: 
Prentice-Hall, 1973) 

e Denning, Peter J., “Virtual Memory,” Computing Surveys, Vol. 2, No. 3 (September 1970) 

¢ Knuth, Donald E., Fundamental Algorithms, Vol. 1 (Reading, Mass.: Addison-Wesley, 1973) 


e Peterson, James L., Petri Net Theory and the Modeling of Systems (Englewood Cliffs, N.J.: Prentice- 
Hall, 1981) 


RELATED PRODUCTS | 


Designers interested in operating systems for the protected-mode iAPX 286 should also be aware of 
Intel’s iAPX 286 Architecture Extension Kernel K28. K286 is an operating-system kernel designed 
for a wide variety of applications, ces real-time, communications, business systems, and time- 
sharing. K286 provides , 


° Short-term, priority scheduling and management of multiple tasks 
e Interrupt management | 

© Multiprocessor support — 

e Virtual memory support 

e Data sharing among tasks with synchronization 

e Intertask signals and messages 


e Extended protection 


Whether you use K286 “as is,” for greatest possible efficiency, or whether you add layers of software 
to more fully support your applications, K286 can significantly reduce your system development time. 
Since K286 has been designed by the architects of the iAPX 286 and implemented and tested by 
Intel’s software engineers, USInE K286 can make your system more reliable. 


K286 implements many of the concepts discussed in this book, ach can n therefore give you additional 
understanding of why and how to use K286. 

HOW TO USE THIS MANUAL 

This manual has two related objectives: 


° To identify features of the iAPX 286 architecture that are unique when applied to the implemen- 
tation of an operating system 


¢ To show how you can esecoNely use these unique features i in the design of familiar operating system 
functions 
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In pursuit of these objectives, Chapters 2 thru 13 share a general, three-part structure: 


1, Identifing an operating system function (or class of functions). The functions chosen are those 
~ with which you might already be familiar, since they are similar to those used in state-of-the-art 
operating systems such as iRMX 86 (from Intel Corporation) or UNIX (from Bell Laboratories). 


2. Reviewing the iAPX 286 features that support that function. While this portion of each chapter 
may cover some material available in other Intel literature, it provides added value by discussing 
in one place all the iAPX 286 features that bear on a given operating eee function and by 
identifying relationships among those features. | 


3. Outlining some examples of how to use those iAPX 286 features in an implementation of the 
identified function. It is, of course, impossible to illustrate all the ways to design any given function, 
but these examples serve to illustrate a few of the ways that the designers of the iAPX 286 archi- 
tecture intended for it to be sapped: 


Chapter 1 introduces the iAPX 286 architecture; identifies the role of an operating system in a protected, 
multitasking environment; and shows how Intel’s Binder and Builder utilities aid in the construction of 
an operating system. You may skip Chapter 1 if you are already familiar with multitasking operating 
systems and with the Binder and the Builder. | 


Both Chapter 2 and Chapter 5 contain key information about manipulating the protection features of 
the iAPX 286. Be sure not to omit these chapters when scanning the contents of the book. 


For the remaining chapters, you may turn directly to the subjects that interest you most. You will find 
the reading easier, however, if you observe the partial orderings outlined in table 0-1. 


NOTATIONAL CONVENTIONS 


UPPERCASE Characters shown in uppercase must be entered in the order shown. You may 
enter the characters in uppercase or lowercase. 


italic Italic indicates a meta symbol that may be replaced with an item that fulfills 
: the rules for that symbol. The actual symbol may be any of the tolowine: 


system-id Is a generic label placed on sample listings where an operating system- 
dependent name would actually be paige: | 


VX.y Is a generic label placed on saiapie fiscned where the version number of the 
product that produced the listing would actually be printed. 


Table 0-1. Prerequisites by Chapter 
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CHAPTER 1 
INTRODUCTION TO PROTECTED MULTITASKING. 
ON THE iAPX 286 | 


The iAPX 286 architecture views the software system (the operating system as well as applications) as 
a number of-asynchronous tasks, each task possibly consisting of levels of procedures deserving differ- 
ent degrees of “trust.” An operating system for the iAPX 286 must (with the help of the hardware) 
coordinate the activities of multiple tasks and administer protection among tasks and among levels of 
procedures within tasks. 


TASKS. 


A task is the execution of a sequence of steps. A program is a logical entity that can have many 
representations: for example, source code file or object program file. A program becomes a task when 
it is actually available for execution. This is achieved by converting source (with a compiler and program 
loader, for example) to a representation suitable for execution and notifying the operating system that 
the task is ready for installation and execution. 


The distinction between programs and tasks is most clear in a multitasking system, where it is possible 
for two or more tasks to use one program simultaneously. The line editor program in a timesharing 
system is a common example. Even though each line editor task uses the same program, each task 
produces different results, since it receives different inputs. 


Structure of a Program 


Each program is formed from modules created by language translators and bound together into a single 
executable unit. The translators (for example, ASM286, PL/M-286, Pascal-286, and FORTRAN-286) 
and the object program utilities (for example, Intel’s Builder and Binder) support the concept of logical 
segments. A logical segment is a contiguous block of either instructions or data. Each logical segment 
can contain up to 64K bytes of code or data. Logical segments are the units that may be combined 
when a program comprises more than one module. 


Segmented Memory 


The iAPX 286 structures the address space of a task into physical segments of variable length. A 
physical segment is a contiguous block of memory that does not (normally) overlap another physical 
segment. Each physical segment may contain up to 64K bytes of either instructions or data. Each 
physical segment contains one or more logical segments of a task. The segments reflect how tasks are 
organized into code, data, and stack areas. , 


Multitasking 


One of the most important features of the iAPX 286 is its ability to switch rapidly from executing one 
task to executing another task. This gives the appearance that the processor is executing more than 
one task at a time. , , 
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Hardware system tables enable both the hardware and the operating system to distinguish between the 
physical segments of individual tasks. Figure 1-1 shows how physical segments of one task are logically 
separate from those of other tasks. Since references to physical segments are always relative to system 
descriptor tables, the actual locations of physical segments in physical memory are not significant to 
the tasks and therefore are not illustrated. 


Descriptor tables serve not only to identify the segments that belong to a task but also to isolate the 
address space of one task from that of another, so that one task cannot inadvertently affect the opera- 
tions of another. | | : 


Multitasking works through close interaction of the operating system with hardware features. When 
the executing task needs to wait for some event (such as the arrival of data from some I/O device), it 
notifies the operating system. The operating system determines which other task should execute next, 
and then causes the processor to store the state of the current task, retrieve the state of the next. task; 
and begin executing the next task at the point where its processing last halted. The processor then 
executes that task until the task needs to wait for some.event. (This is a somewhat oversimplified 
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Figure 1-1. Segregation of Segments by Tasks with Private LDTs 
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description of what can be a complex operating system function. Chapter 4 covers the subject of task 
switching in more detail.) 


Figure 1-2 illustrates how the global descriptor table defines an address space that is accessible to all 
tasks in the system. This global space is useful for translation tables, run-time libraries, Ops EeHe | 
system code and data, and the like. 


PRIVILEGE LEVELS 


The iAPX 286 architecture uses the concept of privilege levels to protect critical procedures within a 
task from less trusted procedures in the same task. For example, with previous generations of micro- 
processors, applications code could access and possibly destroy tables used by the operating system. 
An error of this sort could cause the operating system to incorrectly service a subsequent request from 
another unrelated task. With the iAPX 286, such situations are prevented by hardware-enforced barriers 
between different levels of procedures. : . 
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Figure 1-2. Global Segments in System 
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Applied to procedures, privilege level is a measure of the degree to which you trust a procedure not to - 


make a mistake that might affect other procedures or data. Applied to data, privilege level is a measure 
of the protection you think a data structure should have from less trusted procedures. 


Bavilese level also applies to instructions. Certain instructions (those that deal with system tables, 
interrupts, and I/O, for example) have such an effect on the system as a whole that only highly trusted 
procedures should have the right to use them. 


Levels of Segments 


With regard to privilege, you can view the segments of a task as being grouped into four levels. Level 
zero is for the most privileged procedures and the most private data; level three is for the least trusted 


procedures and the most public data. You (or your operating system) associate each segment of each — 


task with one of these four levels of privilege. The privilege level of a segment applies to all the proce- 
dures or all the data in that segment. Figure 1-3 illustrates the logical segregation of segments into 
privilege levels. (Later chapters explain why operating-system segments are included within the task.) | 
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Figure 1-3. Segment Segregation by Privilege Level within a Task 
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Rules of Privilege 


The 80286 processor controls access to both data and procedures between levels of a task. These rules 
define access rights: 


e Data can be accessed only from the same or a more privileged level. 


e A procedure can be called only from the same level (or from a less privileged level, if the service is. 
deliberately “exported” to that level. Refer to gates in Chapter 2. ). | 


SOFTWARE SYSTEM STRUCTURE 


The way you choose to distribute software and data among tasks and privilege levels affects the relia- 
bility, efficiency, and flexibility of your system. Operating-system modules may be segregated into 
their own tasks or may be distributed among and shared by every task. Some advantages of placing 
operating-system modules in separate tasks are | | 


e Finer granularity of protection is achieved by using task separation as well as privilege levels. 
e Operating-system functions can execute in parallel with the caller. | : 


¢ When only one task at a time can perform the function (for example, reading from a keyboard), 
serialization of requests is automatic; you do not need to synchronize among requesting tasks. 


Some advantages of distributing operating-system functions are 


e The communication between application and operating system is faster. 


e It may be possible for all tasks to execute the same operation-system function in parallel. (You must 
ensure reentrancy and provide for synchronization, however. )- 


Figures 1-4 through 1-7 illustrate some general uaspneaches that you may sonsidet: 


The approach shown in figure 1-4 takes maximum advantage of the four privilege levels. The critical 
procedures and data of the operating system kernel (for example, memory allocation tables and proce-. 
dures, information about tasks) are protected from all other procedures in the system. Those parts of 
the operating system that are less reliable, either due to inherent complexity (for example, the I/O 
subsystem) or due to occasional changes (for example, policies designed to increase overall through- 
put), are at a lower level but are still protected from application levels. Application logic has two levels 
so that application services (such as database management) can be protected from less trusted appli- 
cation code, yet application services cannot affect the integrity of the operating system. Operating- 
system procedures and application services are shared among all the tasks in the system. 


Figure 1-5 illustrates that you do not need to use all four privilege levels. You may prefer this two-level 
approach if you are converting from a traditional multitasking system that once protection only between 
the two levels defined by application and CpetaUns) system. | 


The 1:APX 286 can also emulate one-level systems, as illustrated i in tice 1-6. This approach may be 
useful in the initial stages of converting from an unprotected system, but it does not take advantage of 
many of the protection features offered by the iAPX 286. It does isolate tasks from one PanOUnels but 
it does not protect the operating system from applications software. 


Some operating system functions are better structured as independent operating-system tasks, not as 


privileged procedures within a task. Certain I/O functions are suited to this treatment. Because of the 
complexity of I/O code, the extra protection offered by a task boundary contributes to the reliability 
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Figure 1-4. A Four-Level Protection Structure 


of the system. Because many I/O functions involve waiting for responses from I/O devices, it is most 
convenient to treat these functions as a separate task that can run asynchronously with respect to the 
tasks that invoke them. Figure 1-7 illustrates a structure with independent operating-system tasks. 


ROLE OF THE OPERATING SYSTEM 


The role that an operating system may play in managing a multitasking execution environment depends 
on the nature of the application. Applications can be classified according to the volatility of tasks 
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Figure 1-5. A Two-Level Protection Structure 


executing over a period of time. Applications in which tasks frequently begin and end (for example, 
time-sharing systems or multi-user business systems) are called dynamic systems. Applications in which 
the mix of tasks does not change (for example, process control systems in which tasks service a i fixed 
number of sensors and effectors) are called static systems. : ae 


Common O.S. Functions 


The operating-system roles common to both static and dynamic applications are 


Allocation of the processor or processors to tasks 
Coordination and communication among cooperating tasks | 
Processing of interrupts and exception conditions 
Standardization of interfaces to I/O devices 


Control of the numerics processor extension 
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Figure 1-6. A One-Level Unprotected Structure | 


0.S. Functions in a Dynamic Environment 


Even though many of the duties of an operating system in a dynamic environment resemble those in a 
static environment, the dynamic environment often introduces new complexities. Some additional 
functions that a dynamic system may require include 


_ Real memory management 


Program loading 

Command language interface 
Virtual memory management 
Load-time binding 


CONSTRUCTING THE INITIAL RUN-TIME ENVIRONMENT 


Intel’s System Builder program helps you create the initial executable system. The Builder program 
collects object modules into one module, assigns physical addresses, creates system tables, and assigns 
privilege levels. A specification language gives you the ability to control preciscly what the Builder 
does. See Boise as 
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Figure 1-7. Independent Operating-System Tasks 


Building a Static System 


In the case of static systems, the Builder does nearly all the work in constructing-a running system. 
Refer to figure 1-8 for an illustration of the building process. The output of the Builder is a single 
module that contains all the tasks, both for the operating system and for applications, as well as all 
system tables and protection information. The Builder’s output file has a format that simplifies creation 
of a bootstrap loader for the system. 


Building a Dynamic System 


With dynamic systems, the Builder constructs as much of the final system as you can specify in advance, 
but the nature of dynamic systems is such that the operating system must do at run-time many of the 
operations that the Builder does for static systems (for example, allocation of memory and assignment 
of physical addresses). The operating system must update system tables and administer the protection 
mechanisms as the running environment changes. | 
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Figure 1-9 illustrates the process of constructing a dynamic system. The Builder creates a loadable 

module containing those operating-system functions that permanently reside in the running operating | 
system, and it also creates a file that contains information about linking to operating-system primitives. . 
Either a static linker (such as Intel’s Binder) or a dynamically linking loader can use this information | 
to help dynamically loaded tasks use operating-system functions. | 
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CHAPTER 2 
ou HARDWARE PROTECTION peer: 


The architecture of the iAPX 286 enables you to organize software systems so that each task is protected 
from inadvertent or malicious damage by other tasks and so that privileged procedures are protected 
from lower-level procedures. You control the degree of protection in your system by the way you set 
up protection parameters through the Builder or through operating system procedures. The processor 
interprets the protection parameters and automatically performs all the checking necessary to imple- 
ment protection. 


ADDRESSING MECHANISM 


The protection mechanism of the iAPX 286 is embedded in the addressing mechanism. For an intro- 
duction to the addressing mechanism, refer to figure 2-1, which shows those portions of the addressing 
mechanism that are not concerned with protection features. From the point of view of the applications 
programmer, an address is a pointer. A pointer consists of two parts: a selector and an offset. The 
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Figure 2-1. Abstraction of Addressing Mechanism 
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selector portion identifies a segment of the address space and the offset addresses an item within the 
- segment relative to the beginning of the segment. 


A selector identifies a segment by reference to a descriptor table. Each entry in a descriptor table is a 
descriptor. A selector contains an index that identifies a particular descriptor in a particular descriptor 
table. The descriptor contains the physical address and access rights of the segment. 


Both selectors and descriptors contain additional information that relates to the protection features of 
the iAPX 286. 


DESCRIPTORS 


A reference from one segment to another is realized indirectly through a descriptor, which contains 
information about the referenced segment. All descriptors reside in a descriptor table. Every segment 
must have at least one descriptor; otherwise there is no means to address the segment. 


Descriptors are strictly under your control. via the Builder or operating system procedures. The exist- 
ence and function of descriptors is completely invisible to the applications programmer. | 


Descriptor Format 
There are four variations in descriptor ferinat corresponding to the four classes of deceit stot 


1. Data segment descriptors refer only to segments that contain system or application data, including 
stacks (see figure 2-2). 


2. Executable segment descriptors refer only to segments that contain executable instructions (see 
figure 2-3). 


3. System segment descriptors refer only to segments that contain special hardware-recognized data 
structures, such as descriptor tables (see figure 2-4). 


4. . Gate descriptors define entry points for control transfers. A gate descriptor does not directly sdaness 
a memory segment; instead it provides a.protected pointer to an exported euthy point. Co to 
the section “Gate Descriptors” later in this chapter.) 

The first two types of descriptor hold information that any operating system must maintain. The 

iAPX 286, however, requires that such information be in a fixed format so the CPU can interpret it 

directly. These descriptors are often created dynamically while a program executes (for example, a 

data-segment descriptor may be created when a task needs additional memory to store an expanding 

data structure). 


The second two types of descriptor are unique to the iAPX 286. They are constructed either once when 
the system is built or once when a task is created. Code to manipulate these descriptors is limited to 
the procedures of a dynamic operating system that create new tasks. 


Several of the descriptor formats have common fields. These fields are listed first in the following 
‘discussions of descriptor contents. 


PRESENT BIT 


This Boolean is set if the segment addressed by the descriptor is actually present in memory, reset if 
not present. Operating systems for dynamic applications that implement virtual memory must set and 
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Figure 2-2. Data Segment Descriptor 


reset this bit as program segments are brought into or eliminated from memory. Reference to a segment 
whose present bit is reset causes a fault, providing an opportunity for the operating system to load the 
segment from virtual store. (Chapter 9 takes up implementation of virtual memory systems.) In systems 
that do not implement virtual memory, this bit is always set for allocated segments. : 


DESCRIPTOR PRIVILEGE LEVEL 


The value of this item defines the privilege level of the segment addressed by this descriptor. You - 
control the values in the descriptor privilege level (DPL) by the parameters you give to the builder 
when creating a static system or the resident portion of a dynamic system, or by the procedures your 
Operating system uses when loading segments dynamically. 


INTEL RESERVED 


This portion of the descriptor is reserved by Intel and should always be initialized with zeros. Other 
use of this field in a valid descriptor will prevent compatability with the iAPX 386 and other additions 
to Intel’s family of processors. 
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Figure 2-3. Executable Segment Descriptor 


SEGMENT BASE 


This field contains the physical address of the beginning of the memory segment referred to by this 
descriptor. The 24 bits of this address give the 80286 a 16-megabyte range of real addresses. This is 
the only place that physical addresses are used. All other addresses are relative to the physical addresses 
stored in descriptors, making it possible to relocate executable and data segments without making any 
changes to the relocated segments or to code that refers to the segments. The only changes necessary 
to relocate segments are changes to the physical addresses stored in descriptor tables. 


You can control the actual location of segments by means of specifications to the Builder or by means 
of the algorithms your operating system uses to allocate memory to segments that are. loaded 
dynamically. | 


SEGMENT LIMIT 


Segment limits prevent accidental reading or writing beyond the space allocated to a segment. The 
value of this field is one less than the length of the segment (in bytes) relative to the beginning of the 
segment. The 16 bits of this field make it possible to have segments up to 64K bytes long. The hardware 
automatically checks all addressing operations to ensure that they do not exceed the segment limit of 
the segment to which they refer. This protects other segments from euch common Piegramnuns's errors 
as runaway subscripts. 
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Figure 2-4. System Segment Descriptor 


Note that the segment limit field has a different meaning for ‘ ‘expand down” data segments. Refer to 
the “expansion direction” bit later in this chapter. 


SEGMENT TYPE 


For system segments, the type field distinguishes between kinds of system segments. System segment 
types are 


1 and 3 Task state segment, a segment used for storing the context of a task. Chapter 4 discusses 
task state segments more fully. 7 


2 Local descriptor table. The three kinds of descriptor tables are explained later in this 
chapter. 


The processor interprets the type field to ensure that each segment is actually used as intended; for 
example, an attempt to jump to a local descriptor table is obviously a mistake, and the. processor 
detects this error while examining the target segment’s descriptor during the JMP instruction. 


EXPANSION DIRECTION 


Data segments may contain stacks as well as other data structures. Stacks expand toward lower addresses 
while most other data structures expand toward greater (higher) addresses. This field indicates the 
growth pattern for the segment. A value of zero in this field indicates that the segment expands upward 
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(from the base address toward the segment limit value that is also contained in the descriptor). A value 
of one indicates that the segment expands downward (from offset FFFFH toward the limit). 


WRITABLE 


This field applies only to data segment descriptors. A value of one permits the CPU to write into the 
segment; a value of zero protects the segment from attempts to write into it. Translation tables are but 
one example of data that deserve the extra protection afforded by storage in a read-only segment. 


CONFORMING 


This field applies to executable-segment descriptors only. Ordinarily (when the conforming bit is zero) 
a called procedure executes at the privilege level defined by the DPL in the descriptor of the segment 
in which the procedure resides. When the conforming bit of the called segment is set, however, the 
called procedure executes at the calling procedure’s privilege level. This feature cannot be used to 
decrease (numerically) a segment’s privilege level below that defined by it’s DPL. Figure 2-5 shows 
graphically how a conforming segment works. This feature is useful when you want to make procedures 
- (mathematical subroutines or run-time support procedures, for example) available to a number of other 
procedures running at different privilege levels, but when you do not want to provide increased privi- 
lege while the subroutine is executing. 
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Figure 2-5. Calling a Conforming Segment 
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READABLE 


This field applies only to executable-segment descriptors. When reset, it prevents procedures in 
other segments from reading this code segment; the contents of the segment can be executed only. 
It is common, however, for executable segments to contain read-only. data, in which | case this bit 
must be set. 


ACCESSED 


The processor sets this bit when the descriptor is accessed (that is, loaded into a segment. register or 
used by a selector test instruction). Operating systems that implement virtual memory may, by period- 
ically testing and resetting this bit, monitor frequency of segment usage. This bit also indicates whether 
a segment should be written to secondary storage before the RAM space it occupies is reused. 


CONTROL FLOW TRANSFER 


Transters of control 2 are also aabieet to pegtection rules. Within the application- oriented: part of z a task, 
the protection rules allow unlimited access to code and data. Control transfers to privileged operating- 
system functions and to other tasks, however, are controlled by gate descriptors. With gate descriptors, 
the iAPX 286 architecture can perform functions in hardware that operating systems on other proces- 
sors must do in software. These functions are invoked directly by ordinary CALL and JMP, instruc- 
tions, not by special interrupt or trap instructions. 


As table 2-1 illustrates, transfers of control can be classified into four categories, depending on whether 
control passes to another segment, another privilege level, or another task. This ee ucone can DEP 
clarify how privilege levels, descriptor tables, and tasks are used. Pee . 


_ Processor functions that cause a cnenee in une flow of control are» 


e Jump instruction (JMP) 

¢ Procedure call instruction (CALL) 

e Procedure return instruction (RET) 
e Software interrupt instruction (INT) 


e External interrupt 


Table 2-1. pcalccicabied of Control Flow Transfer 


aa ‘ - Privilege 


Interlevel different different 


same same 
Intertask or or | different 
different different . 
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e Processor-detected exception condition 

e Interrupt return instruction (IRET) 

Control transfers within the same privilege level may be. either short (within same segment) or long (to 
another segment). A short transfer simply specifies the offset of the instruction to which control is 


transferred in the same segment. A long transfer also uses a selector to identify the segment to which 
control is transferred. 


For control transfer to a different privilege level or different task, the iAPX 286 ‘nivoduces gate 
Gee 

Gate Descriptors 

A gate descriptor is a type of descriptor used only for transferring control flow to instructions in another 
segment. Gates provide an indirect reference that is useful for binding and protection purposes. By 
requiring interlevel and intertask control transfers to reference gate descriptors, the iAPX 286 pIOvIees 


two aon protection features: 


1. You can hide a procedure by not providing a gate for its entry point. 


2. You can control access to a procedure via the privilege assigned to the abate: This allows hiding 
critical procedures from untrusted software. 


Figure 2-6 illustrates the format of a gate descriptor. 


DESTINATION SELECTOR 
For call, interrupt, and trap gates, this field contains a selector for the segment descriptor of the desti- 


nation executable segment. For task gates, the selector in this field points to a igi see for a task 
state segment, and the RPL field is not used. 


DESTINATION OFFSET 


For call, interrupt, and trap gates, this field contains the offset of the entry point within the destination 
executable segment (not used with task gates). 


WORD COUNT 
For each privilege level within a task, there is a separate stack: For calls through a call gate, the 


processor automatically copies parameters from the stack for the calling procedure’s privilege level to 
the stack for the destination’s privilege level. In this field, you specify the number of words to copy. 


GATE TYPE 
For gate descriptors, the type field distinguishes among the four kinds of gates: 


0 Call gate ; 7 
1 Task gate 
2 Interrupt gate 
3 Trap gate 
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Figure 2-6. Gate Descriptor 
PRESENT BIT 
Since a gate descriptor does not refer directly toa segment, the present bit in a gate descriptor does 


not necessarily indicate whether a segment is present. It can be used for other purposes, however. Refer 
to Chapter 11 for an example of using the present bit to facilitate late binding. 


Control Transfer Mechanisms 
Table 2-2 summarizes the mechanisms for each class of control flow transfer. 


Control transfers within a segment function similarly to intrasegment transfers on the iAPX 86,88, 
except that the processor checks that the destination address does not exceed the segment limit. 


Figure 2-7 illustrates a change in control flow between segments at the same privilege level. Any of 
the following instructions can effect such a transfer: 


JMP offset selector 

CALL offset selector | 

RET 3; (offset and selector taken from gnc. 

The selector selects a descriptor for an executable segment. The DPL in the target segment’s descrip- 


tor must be the same as the privilege level under which the calling segment is running. A CALL or 
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Table 2-2. Control Transfer Mechanisms 


Transfer Descriptor 


CALL, JMP Call gate © GDT/LOT 
(same PL) 


INT instruction, trap or 
external interrupt, interrupt 
or exception _ gate (same PL) 


Intersegment 


(*) 


Interlevel 


INT instruction, trap or 
external interrupt, interrupt 
or <> See gate 


CALL, JMP, IRET task state 
segment 


INT instruction, 
external interrupt, 
exception 


Intertask 


task gate 


* Includes cases in which the target segment is incidentally the same as the calling segment. 


JMP instruction may also reference a call gate. If the target executable segment is at the same privi- 
lege level, no level change occurs. 


For transfers of control between segments at different privilege levels (as illustrated in figure 2-8) there 
are three differences: 


‘e Only the following instructions can be used: 


CALL offset selector 
RET 


Jumps between privilege levels within a task are not allowed. 


¢ The selector does not select the descriptor of an executable segment but rather selects a gate 
descriptor. 


_ The offset operand must be spe abit but i is ignored. . 
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Figure 2-7. Intralevel Control Transfers 


Privilege Rules for Gated Intersegment Transfers 
An intersegment transfer through a gate involves four privilege level fields: 


e The current privilege level (CPL) of the currently executing segment 
e The requested privilege level (RPL) in the selector used in the CALL 
¢ The DPL in the gate descriptor 


e The DPL in the segment descriptor of the target executable segment 
A transfer is valid only if the following relationships among privilege level numbers both hold: 


MAX (CPL, RPL) <= gate DPL 
target DPL <= CPL ~ 


Figure 2-9 illustrates both valid and invalid attempts to perform an interlevel transfer. Path E4,G5,E7 
is not valid because the privilege level of gate G5 is numerically less than that of segment E4. Path 
E4,E8 is not valid because all interlevel transfers must pass through a gate. Path E4,G4,E6 is not valid 
because the privilege level of E6 is numerically greater than that of G4. Only paths E1,G2,E2; E1,G1,E3; 
and E2,G1,E3 satisfy the privilege rule above. 
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Figure 2-8. Gated Interlevel Call and Return 


DESCRIPTOR TABLES 


A descriptor table is simply a segment containing an array of eight-byte entries, where each entry is a 
descriptor. Descriptors are stored in one of three classes of descriptor table: | 

* Local descriptor table (LDT) 

* Global descriptor table (GDT) 


¢ Interrupt descriptor table (IDT) | 


The descriptors in these tables define al/ the segments in the system. Each table has a variable upper 
limit, so the size of the table need be no larger than required for the actual number of segments used. 


You define the initial contents of descriptor tables through the Builder. An operating system for dynamic 
applications may change the contents of descriptor tables and may create and delete LDT’s as tasks 
come and go. Correct management of descriptors is the heart of protection on the iAPX 286. 
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Figure 2-9. Valid and Invalid Interlevel Transfers 
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Local Descriptor Table 


An LDT contains the descriptors that are private to a task. Each task may have an LDT. The LDT 
keeps the descriptors private to one task separate from those private to other tasks. A task cannot 
normally gain access to the segments defined by another task. A local descriptor table may contain any 
of the following types of descriptor: 


e Data segment 

e Executable segment 
¢ Call gate 

e Task gate 


The executable segment and data segment descriptors in an LDT normally refer to segments private 
to a task. Call gates and task gates in an LDT provide private entry points to other procedures and 
programs. 


The processor uses a task’s LDT automatically for certain addressing operations. The base address and 
limit of the LDT segment of the executing task are kept in the LDT register. Only two operations are 
available to programmatically change the contents of the LDT register: 


e During a task switch operation, the processor loads the LDT register from the task state sean 
(TSS). 


¢ The LLDT instruction loads the LDT register directly. The LLDT instruction can be executed only 
at privilege level 0 (PL 0). Initialization procedures use LLDT to give the LDT register its initial 
value. Note that if you change the LDT register you must also change the LDT selector in the TSS 
(refer to Chapter 4). An operating system may need to change the LDT register temporarily to gain 
access to the address space of another task when passing information between tasks. 


You can use the SLDT instruction to read the contents of the LDT register. Operating-system proce- 
dures that operate on LDTs may usually be called from any task. These procedures may use the SLDT 
instruction to find which LDT belongs to the current task. In PL/M-286, the built-in variable 
LOCALSTABLE gives access to the LDT register. 


An LDT may contain up to 8,192 descriptors (the number of 8-byte descriptors that fit into a maximum- 
sized segment of 65,536 bytes). 


Global Descriptor Table 


Descriptors that are shared among tasks reside. in the GDT. There is only one GDT for the entire 
system. The GDT can contain any of the following types of descriptor: 


¢ Data segment 

e Executable segment 

e Task state segment 

e Local descriptor table segment 
e Call gate 

e Task gate 


2-14 121960-001 


intel USING HARDWARE PROTECTION FEATURES 


Since the GDT is shared among all tasks, its entries are usually protected. The privilege-level field in 
each descriptor provides this function. When operating-system functions are distributed among and 
shared by all tasks, the executable segments and data segments of the operating system are normally 
kept in the GDT. Call gates then provide controlled access to privileged operating system functions. 


The processor uses the GDT automatically for certain addressing operations. The base address and 
limit of the GDT are kept in the processor’s GDT register. Only the LGDT instruction 
(RESTORE$GLOBALS$TABLE in PL/M-286) can alter the contents of the GDT register, and the 
LGDT instruction can be executed only at PL 0 (i.e., by the operating system). 


The SGDT instruction (SAVESGLOBALSTABLE in PL/M-286) reads the contents of the GDT 
register. 


A GDT may contain up to 8,191 descriptors (the number of 8-byte descriptors that fit into a maximum- 
sized segment of 65,536 bytes). The first entry cannot be used as a descriptor. (A null selector is 
identified by the fact that it refers to this first entry in the GDT.) 


Interrupt Descriptor Table 


When processing an interrupt, the processor refers to the IDT to determine what interrupt-handling 
code to execute. Each interrupt is associated with an interrupt identifier, an integer that ranges from 
0-255. The interrupt identifier is supplied either by the INT instruction or externally by the BIncesson S 
INTA cycles. The interrupt identifier indexes an entry in the IDT. An IDT entry may. be | 


e An interrupt gate 

e A trap gate 

e A task gate 

In a manner similar to executable segment and data segment descriptors, each gate descriptor has a 
descriptor privilege level. The DPL of a descriptor in the IDT determines the privilege required to 
execute an INT 7 instruction (where n is the interrupt indentifier that corresponds to the descriptor). 
This use of privilege levels prevents unauthorized programs from invoking interrupt handlers. 

The processor locates the IDT by way of the IDT register. The IDT register can be changed only by 
the LIDT (load IDT) instruction (RESTORESINTERRUPTSTABLE in PL/M-286). Only PL-0 
proceeures (i.e., the operating system). can execute an LIDT instruction. 


The SIDT instruction (SAVESINTERRUPTSTABLE in /PL/ eee reads the contents of the IDT 
register. | 


Refer to Chapters 6 and 7 for more detailed information on how the IDT is used. 


SELECTORS 


A selector references a segment indirectly by identifying the location in a descriptor table where a 
descriptor for that segment is stored. ae , 


Format of Selector 


See figure 2-10 for the format of a selector. 
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Figure 2-10. Format of a Selector | 


INDEX 


The index field of a selector specifies a descriptor in either the GDT or the task’s LDT. The index field 
may take on values from 0 through n—1, where nis the number of descriptors in the table. The 
processor compares the index with the limit of the descriptor table to ensure that the index refers to a 
defined descriptor. 


TABLE INDICATOR 


This bit item tells which descriptor table is indexed by the selector. A value of zero specifies the GDT; 
one specifies the LDT. (The IDT cannot be referenced via a selector; only via an interrupt identifier.) 


REQUESTED PRIVILEGE LEVEL 


Selector privilege is specified in the RPL field of a selector. Selector RPL may establish a less trusted 
privilege level than the current privilege level for the use of that selector. RPL cannot effect an increase 
in privilege. A task’s effective privilege level is the numeric maximum of the RPL and the current 
privilege level. For example, if a task is executing at PL = 2, an RPL = 3 reduces the task’s effective 
privilege to level 3 for access to that segment. On the other hand, if RPL = 1, the task’s effective 
privilege level remains at 2. | 


RPL is generally used by an operating system to ensure that selector parameters passed to the more 
privileged levels of the operating system do not give access to data at a level more privileged than the 
calling procedure. The RPL field is a convenient place -to store the privilege level of the procedure that 
originated the selector. Any use of the selector can be restricted to the usage allowed its originator. 


The ARPL instruction (ADJUST$RPL built-in function in PL/M-286) allows the operating system to 
set the RPL of a selector either to CPL or to the privilege level of the originator, whichever is cumer 
ically) larger. Refer to Chapter 13 for more information on the use of RPL. 
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Null Selector 


A selector that has a value of zero in both the index and table indicator fields (i.e., appears to point to 
the first entry of the GDT) is a null selector. You can load such a selector into the DS or ES register, 
but any attempt to reference memory via that register causes an exception condition. 


ALIAS DESCRIPTORS 


The need arises in dynamic applications for the operating system to maintain more than one descriptor 
for a segment; however, care must be taken to preserve system integrity and protection. 


As an example of the need for an alternate descriptor, consider the case of an executable segment. 
Ordinarily, the processor fetches instructions from an executable segment that is typed execute-only. 
However, if the operating system supports a debugger, the debugger needs to read the executable 
segment in order to display its contents. The debugger may also need to write to the executable segment 
in order to set breakpoints. If the debugger tries to use an execute-only segment descriptor to read 
from or write to the segment, the processor detects a protection exception. To properly use that segment, 
the debugger must use another descriptor that identifies the segment as a data segment. Figure 2-11 
illustrates this situation. 


The use of more than one descriptor for a segment is known as aliasing. Descriptors used in this way 
are known as aliases, because they provide alternate names for segments. 


ae O.S. 

APPLICATION DEBUGGER 

| . LDT 

EXECUTE ONLY 3 : DATA SEGMENT 
E | 

ORE SEGMENT " INSTRUCTIONS | 
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Figure 2-11. Aliasing for Debugger 
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Explicit Variation of Type 


Figure 2-11 illustrates one kind of need for aliasing: the need for a different type specification for a 
segment. Figure 2-12 shows another example of the same need. In a dynamic application, the operating 
system: may need to modify the GDT, the IDT, TSSs, and LDTs. Changing the interrupt handler for 
a specific interrupt vector requires changing the IDT. When the operating system places a new segment 
into the address space of a task (as, for example, when transferring an I/O buffer from an I/O task), 
it must update the task’s LDT. Starting a new task may require modification of the GDT to add 
descriptors for the new task’s LDT and TSS. 


With the iAPX 286, however, it is not possible to read or write a system.segment by loading its selector 
into DS or ES. This restriction prevents indiscriminate use of system segments within the operating 
system. Such use of a system segment requires that the operating system have a Geseuplor that identi- 
fies the system segment'as.a data segment. | 


The Builder allows for defining aliases for system segments. The Builder, by default, creates data- 
segment aliases for the GDT and the IDT at fixed locations in the GDT. 


Note that aliases for descriptor tables should have PL 0i in order to maintain the integrity of. the protec- 
tion mechanism; otherwise, procedures outside the operating system could indiscriminately change the 
contents of descriptor tables. | : 


Variation of Length 
As illustrated in figure 2-13, aliases for a segment need not always have the same length. In the case 
shown, the processor’s use of a descriptor to a TSS requires only that the segment contain 44 bytes. 


However, the operating system maintains another descriptor that includes additional information about 
the task. 


ALIAS GDT . 
ALIAS LDT 
| ALIAS IDT | IDT ae 


@ ALIAS FOR GDT SHOULD ALWAYS BE AVAILABLE TO KERNEL. 
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Figure 2-12. Aliases for System Tables 
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Figure 2-13. Aliases with Differing Limit 


Sharing Segments among Tasks 


Yet another reason for using aliases is the need for sharing a segment among tasks. Consider an appli- 
cation in which a memory-mapped video display shows status information for a production process. In 
this application, there are two tasks, each monitoring different aspects of the process but interleaving 
data on the display (see figure 2-14). Figure 2-15 illustrates how both tasks can access the memory 
segment containing the display buffer. 


You can find segment sharing needs of this sort in both static and dynamic systems. Note that there 
are other techniques for segment sharing that do not use aliases; for example, placing the segment’s 
descriptor in the GDT, or permitting tasks to share a single LDT. The aliasing technique illustrated 
here has the advantages that 


e No other tasks have access to the display buffer. (Putting its descriptor in the GDT makes it avail- 
able to all other tasks.) 


e Other segments in each of the tasks remain protected from the other task. (With a shared LDT, all 
segments of each task are accessible from the other.) 


Protection and Integrity with Aliasing 


You must use aliases with care; improper use can compromise the protection and integrity of your 
system. | , 
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Figure 2-14. Application of Segment Sharing 


CONTROL ACCESS TO ALIASES 


When you use an alias to provide an alternate type for a system segment (to write to an LDT), any 
procedure that has access to that alias also has unlimited power to affect the entire system. Therefore, 
in constructing an operating system that uses such aliases, you must restrict them to the highest privi- 
lege levels of the operating system; that is, the DPL of such aliases should always be zero. 


PLAN FOR CHANGE 


When you design a dynamic system that uses aliases for segment sharing, you must consider what will 
happen when there is any change in a segment to which aliases are pointing. For example, when a 
segment is relocated, all descriptors pointing to the relocated segment must be updated. When a segment 
is ‘deleted, all aliases to it must be nullified. Chapter 5 presents a strategy for handling these changes. 


EXAMPLE OF DESCRIPTOR MANIPULATION 


As an example of how to manipulate descriptors and descriptor tables using an alias, consider the 
procedures POINT_AT and NULLIFY in figure 2-16. POINT_AT creates a descriptor at a given slot 
in the GDT. NULLIFY invalidates a descriptor in the GDT. It is intended for use in connection with 
POINT_AT to prevent accidental use of descriptors that are no longer needed. . 
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Figure 2-15. Aliases for Segment Sharing 


NULLIFY invalidates a descriptor by writing a value of 80H in the access rights byte. A value of 80H 
is invalid because it indicates a system segment of type zero, but no type zero is defined for system 
segments. 


POINT_AT purposely loads the access rights byte of the descriptor last, to ensure that an accidental 
use of the descriptor (as might occur if an external interrupt gives control to another procedure or task) 
does not find partially complete information in a descriptor that otherwise looks valid. 


These procedures do no checking of the privilege level of the calling procedure, and they freely create 
descriptors of any type (except gate descriptors) and any DPL. Therefore, they are suitable for use 
only at PL 0. As long as no gates for these procedures are provided at another privilege level, they can 
be called only by other PL-0 procedures. For an example of how you might use such procedures, refer 
to the example of a memory manager in Chapter 3. | 


When writing code to manipulate descriptors, you must be careful about changing a descriptor that is 
currently loaded in either of the processor’s data-segment registers (DS or ES). Either disable inter- 
rupts or move zero to the register before changing the descriptor, for example: 


MOV DS, 0 
Failure to do this leaves open the possibility that an external interrupt may cause the processor to 
reload the segment register using the partially modified descriptor. When coding in PL/M-286, use 


the compiler’s CODE option to view the way the generated code handles the DS and ES registers. This 
situation does not arise in the present example. DS points to the data segment that contains the sole 
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global data item GDTA_SEL. PL/M-286 uses ES for all the BASED variables used here. Referencing 
the descriptor table via its alias selector causes PL/M-286 to load ES with the alias descriptor, thereby 
ensuring that ES does not contain the descriptor to be modified. 


Remember that once a descriptor has been modified, it cannot be used to access a segment until it is 
loaded into a segment register. 


Be aware also that in a multitasking system, changes to shared segments (such as the GDT) must be 
synchronized. Synchronization is the subject of Chapter 5. This example does not provide for 
synchronization. 


SLOT MANAGEMENT 


The previous example assumes that the caller of POINT_AT already knows what descriptor-table slot 
to use. Often, slots can be reserved in advance for specific operating system and applications functions. 
But in general, dynamic systems require that the operating system dynamically allocate descriptor 
table slots. | 


Figure 2-17 illustrates a way of identifying available slots in a descriptor table. A value of zero in the 
access rights byte is invalid for any descriptor, so it can mark a free slot. A value of 80H (as used in 
the previous example) is also invalid and can mark a reserved but unused slot. 


In larger systems, the time needed to search a descriptor table linearly for free slots may become 
excessive. Shorter search times may result from linking available slots together in a manner similar to 
that shown in figure 2-17. Contiguous free slots are treated as a block, with a count of the number of 
slots in the first and last slots of the block. (Note that the block size is stored in the reserved word of 
available descriptor slots. Since available descriptor slots contain an invalid type code, this use of the 
reserved word does not prevent upward compatibility.) All the free blocks are linked in a circular, two- 
way list that includes the list header. The list header can reside at a fixed slot location that is the same 
in all descriptor tables (in the case of figure 2-17 the list header is at slot number one). Algorithms 
normally used for managing memory space may also apply to blocks of free descriptors. Refer: to 
Chapter 3 for an example of such an algorithm. 


It is convenient for the operating system to use adjacent descriptor slots for related purposes;.for example, 
by locating together all the descriptors that the operating system uses for one task, the operating system 
can quickly find any of those descriptors as long as it knows the location of one. Therefore, the algorithm 
used for slot management should combine adjacent free slots into a single block. The procedures used 
to manage free slots should then have a parameter that specifies the number of adjacent slots. 


2-22 121960-001 


ntel USING HARDWARE PROTECTION FEATURES 


PL/M-286 COMPILER 960-505 date PAGE 1 


system-ID PL/M-286 Vx.y COMPILATION OF MODULE ‘POINT 
OBJECT MODULE PLACED IN :F1l: POINT. OBJ 
COMPILER INVOKED BY: PLM286.86. :Fl:POINT. PLM 


$ PAGEWIDTH(71) TITLE(' 96G- 5@5') INCLUDE. (:F1:NUCSUB. PLM) 


= S NOLIST 
jee POINT: DO; 
[BR RRR RRR KKK KR RRR RRR HK RIKKI KK KKK KK KKK RHR RK / 
/* Global declarations. i 4 
Qe 4 DECLARE DESC_STR LITERALLY 
‘LIMIT WORD, 
LO BASE WORD, | /* Format of a descriptor. */ 
HI BASE BYTE, 
RIGHTS © BYTE, 


ane RESRVD WORD'; 


3 1 DECLARE DT _SIZE LITERALLY '206', 
GDTA SEL SELECTOR, /* Points to GDT alias */ 
GDTA _WSEL WORD AT (@GDTA_SEL) 
INITIAL (8); /* Slot #1 by convention */ 
GDT . +: ‘BASED GDTA- “SEL (DT _SIZE) 
STRUCTURE (DESC _STR); 


Suxhnue SRG ERY SERE AAR ERNENA CHARS URE AN OE KAO INARI EY 


/* Subroutine to determine either the alias for */ 
7/* the GDT or the alias for this task's LDT, * / 
/* depending on the TI bit in SEL. * ie 
4 1 FIND DT ALIAS: PROCEDURE (SEL) SELECTOR 
PUBLIC REENTRANT; 
5 2 DECLARE SEL ~ SELECTOR, 
WSEL WORD AT (@SEL); 
6 2 DECLARE LDT. SEL SELECTOR, 
LDT WSEL WORD AT (@LDT_SEL); 
7 2 IF (WSEL AND @@0@4H)=@. 
THEN /* It's a selector to the GDT. */ 
8 2 RETURN GDTA_ SEL; 
9 2 ELSE DO; /* It's a selector to this task's LDT. */ 
10 3 LDT_SEL=LOCALSTABLE; /* PL/M 286 built-in; stores a 
selector to the GDT descriptor for this task's LDT. */ 
11 3 LDT_WSEL=LDT_WSEL+8; /* Add 1 to index field. */ 
/* By convention, next slot bolas alias. “7 
12 3 RETURN LDT SEL; 
13 3 END; 
14 2 END FIND DT ALIAS; 
S$ EJECT 


| Figure 2-16. Descriptor Manipulation Example 
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/* Create a descriptor at a given slot to a given  § -*/ 
/* segment, and return selector that points * / 
/* to that slot. */ 
15 iL POINT AT: PROCEDURE (SLOT, RIGHTS, PHYS ADDR-PTR, LIMIT) 
PUBLIC REENTRANT; 
16 2 DECLARE SLOT SELECTOR, 
SLOTW WORD AT (@SLOT) , /* ‘Alternate type 47 
RIGHTS ‘BYTE, 


PHYS ADDR PTR POINTER, 

PHYS _ADDR | BASED PHYS ADDR PTR STRUCTURE 
(LO _ WORD WORD, - 
HI WORD WORD), 

LIMIT WORD; 


17 2 DECLARE SLOTI WORD, /* Slot index */ 
DTA SEL SELECTOR, /* To be set to either 
GDT alias or LDT alias. */ 
DT BASED DTA _SEL (DT SIZE) 
STRUCTURE» ESS _STR); 


18 2 DTA SEL = FIND DT. ALIAS (SLOT) ; 
19 2 SLOTI = SHR(SLOTW, 3); /* Expose index value. */ 
20 2 DT (SLOTI) .LO _BASE = PHYS ADDR.LO_ WORD; 
2.1 2 DT(SLOTI).HI_BASE = LOW(PHYS ADDR.HI_ WORD); 
22 2 -'DT (SLOTI) -LIMIT = LIMIT; 
23. 2 DT (SLOTI) .SW_RESRVD = @; 
24 2 DT (SLOTI) .RIGHTS = RIGHTS; 
25 2 RETURN; 
26 402 END POINT AT; 
[BERK KHER KERR R ERR KK RRR KK HERE KEKE RK KK KERR EEK KAR KK RK RK / 
/* nyalsdace: descriptor indexed by SLOT. */ 
27 1 NULLIFY: PROCEDURE: (SLOT) PUPERC REENTRANT; 
28 2 DECLARE SLOT SELECTOR, 
SLOTW WORD AT (@SLOT); /* Alternate type */ 
29 2 DECLARE SLOTI WORD, /* Slot inaee: * / 
DTA_SEL SELECTOR, /* To be set to either 
=a GDT alias or LDT alias. */ 
DT. BASED DTA_SEL (DT SIZE) 
STRUCTURE (DESC STR); 
30 . 2 DTA SEL = FIND _DT_ ALIAS (SLOT); 
31 2 SLOTI = SHR(SLOTW,3); /* Get index part of selector. */ 
32 2 DT(SLOTI) .RIGHTS = 86H;/* This invalid value prevents 
use of the descriptor. a7 
33 2 RETURN; 
34 2 END NULLIFY; 


[BERR ERE ERR EREKREREEE REE ERERERERKRERERERERER / 


Figure 2-16. Descriptor Manipulation Example (Cont’d.) 
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35 END POINT; 


MODULE INFORMATION: 


CODE AREA SIZE 
CONSTANT AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
129 LINES READ 

@ PROGRAM WARNINGS 
@ PROGRAM ERRORS 


DICTIONARY SUMMARY: 
96KB MEMORY AVAILABLE 
5KB MEMORY USED (58) 
OKB DISK SPACE USED 


END OF PL/M-286 COMPILATION 


Figure 2-16. Descriptor Manipulation Example (Cont’d.) 


2-25 121960-001 


(96-% 


LO0-O961L21 


RESERVED 


SLOT FORMAT 


[| AVAILABLE 


Figure 2-17. Available Siot List 


121960-51 


SSYNLVAS NOILDSLOYd SYVMGYVH ONISN 


Real Memory Management 


CHAPTER 3 
REAL MEMORY MANAGEMENT 


In dynamic applications, when tasks begin and end frequently, the operating system is responsible for 
allocating memory to tasks. Without the control that an operating system provides, independent tasks 
cannot be trusted to share the system’s memory harmoniously. The iAPX 286, through the descriptor 
mechanism, gives the operating system the power to control memory usage. For static systems, you can 
use the Builder to allocate memory. This chapter presents an example of how to manage real memory 
dynamically, using dynamically created descriptors. 


MEMORY MANAGEMENT FUNCTIONS 


Procedures at various levels in a system have a need to get memory for their use. Some of the functions 
that use memory dynamically include 


e Loading the code and data segments for a new task 

e Creating the TSS and LDT of a new task 

e Expanding an application data structure 

e Expanding system stack segments when stacks grow too large 
e Allocating buffers for a newly opened file | 


In allocating memory statically using the Builder, you or the Builder must keep account of what memory 
locations are available and what locations are used. A dynamic memory allocation module must do the 
same, but, in addition, it needs to reuse the space vacated by tasks that have finished. Even tasks that 
are still executing may no longer need all of the memory they once were using, so you need to provide 
some means for them to return that space dynamically. The need to reclaim formerly used memory 
space provides considerable challenge to operating system designers. 


Protection usuaily requires that segments not overlap. The operating system should accurately keep 
track of allocated memory to prevent new segments from overlapping current segments. 


Allocation of memory to tasks in a dynamic environment is complicated by the facts that segments 
have differing lengths and that the order of creation and deletion is unpredictable. Consequently, after 
a number of tasks have come and gone, memory becomes fragmented, as illustrated in figure 3-1. It 
becomes increasingly difficult to find free areas large enough to accomodate requests for space. It may 
happen that no single free area in all of memory is large enough to fill a request for memory even 
though the total of all smaller available areas is larger than the amount needed. Knuth (see “External 
Literature” in the Preface) discusses how various memory-management mechanisms can minimize or 
magnify this problem. | 


Memory management on the iAPX 286 differs from memory management on other processors in that 
descriptors must be constructed to access any region of physical memory. 


EXAMPLE OF A MEMORY MANAGER 


As an example of how a memory manager can manipulate descriptors and segments, consider a memory 
management module that implements a version of the “first fit” algorithm (as described by Knuth) 
and combines adjacent free segments as a way to reduce fragmentation. This example employs the 
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Figure 3-1. Memory Fragmentation 


“first fit” algorithm because it provides an opportunity to illustrate how to create descriptors dynami- 
cally to access free memory areas, not because it necessarily performs best in any pec application. 
Knuth discusses other algorithms, including the “buddy system.” 


Figure 3-2 illustrates conceptually the structure of this module. Hidden inside the module are the list 
of available memory space, the aliases that permit modification of the GDT and LDTs, and the space- 
management algorithms. The PUBLIC procedures ALLOCATE and FREE are the only interfaces 
with the world outside the module. | 


Data Structures 


Figure 3-3 illustrates the data structures implemented in this example memory manager. One-word 
tags bound every memory area on the low and the high end. These boundary tags indicate whether the 
area is free or in use by some task. Free areas are chained into a two-way linked list that uses physical 
addresses to point to the next and prior segments in the list. The size of an area (in bytes) is stored 
with the link addresses in the low-addressed end of the area. At the high-addressed end, a physical 
address points to the beginning of the area. © 


With boundary tags at both ends of every memory area, the memory manager can, when freeing a 
segment that is no longer needed, easily determine whether either of the adjoining areas is free. Figure 
3-4 illustrates how adjacent free areas can be combined to reduce memory fragmentation. 


Figure 3-5 illustrates that boundary tags are invisible to procedures outside the memory management 


module because the tags are not within the base and limit addresses in the segment descriptor that the 
memory manager returns to the caller. 
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Figure 3-2. Information Hiding in Memory-Management Example 


This memory manager does not maintain descriptors to free segments; instead, it creates descriptors 
dynamically when it needs to address the boundary tags and space-management linkages. This policy 
minimizes the number of Sos a in oe GDT. Note that as a result, free areas may be Target than 
64K bytes. , 


Physical addresses are stored as double words (DWORD) to take advantage of double word arithmetic 
in PL/M-286. In an actual implementation, you may :wish to store physical addresses in three-byte 
fields to save space, but you would need to implement arithmetic operations for three-byte operands. 


The total size of the memory-management items associated with each free area is 20 bytes; therefore, 
to ensure that no memory area is too small to contain the memory-management items, this algorithm 
chooses the size of the allocated space to be a multiple of the next integer greater than 20 that is also 
a multiple of 16. This number is identified as BLOCK_MODULUS. 
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Figure 3-3. Example Memory-Management Data Structures 


The memory manager maintains physical-address pointers to the first segment in the available segment 


list and to the last. It also maintains a “‘current available” pointer that corresponds to Knuth’s “roving 
pointer.” iene | : | 


This example also makes some assumptions about the placement of descriptors in the GDT. Figure 
3-6 illustrates these assumptions: 


¢ ‘The memory manager frequently needs to create temporary descriptors for such purposes as reading 
and updating the boundary tags and link fields. For its own convenience, the memory manager 
reserves GDT slots for these temporary descriptors. This example identifies the slots as SLOT_A, 
SLOT_B, and SLOT_C. 


¢ Adjacent slots in the GDT contain all the descriptors to information for one task. This way, given a 
selector for one task descriptor, simple addition or subtraction yields selectors for other descriptors 
for the same task. | | : se | 
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Figure 3-4. Using Boundary Tags | 
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Figure 3-5. Hiding Boundary Tags 


There are two ways to reserve slots in a descriptor table: 


1. Code absolute selector values in the program and use the Builder’s RESERVE statement to prevent 
the Builder from allocating other descriptors to those slots. This is the method used in this example. 


2. Use EXTERNALs to dummy segments coded in an ASM286 module, and allow the Builder to 
assign slots for the descriptors of the dummy segments. The Builder resolves the EXTERNALSs. | 


PL/M-286 Code 


This example separates space-management functions from descriptor-management functions. The space- 
management procedures are DELINK, FIND_FIRST_FIT, and RETURN_SPACE. The public 
procedures ALLOCATE and FREE_SEG call on POINT_AT and NULLIFY to manipulate descrip- 
tors for allocated segments. (Refer to Chapter 2 for definitions of POINT_AT and NULLIFY.) 


The PL/M-286 built-ins used to manipulate system structures in this example include 


SELECTORS$QF (pointer) 

GETSSEGMENTS$LIMIT (Cselector) 

The external procedure GET$SEGMENTS$BASE extracts the segment base address from the speci- 
fied descriptor. 


When the procedure FIND_FIRST_FIT finds an available space that is much larger than requested, 


it allocates the higher-addressed portion of the space and leaves the lower-addresscd portion in the free- 
space list. Figure 3-7 illustrates the process of: splitting an available space. 
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Figure 3-6. Example GDT Layout 


When returning an unneeded segment to the available list, the procedure RETURN_SPACE checks 
the boundary tags of both the lower and higher adjacent segments to see whether there is another free 
segment with which to combine. Four cases are possible, as illustrated in figure 3-8 at the end of this 
chapter. Table 3-1 summarizes the actions taken in each of the four cases. 3 


- See figure 3-9 at the end of this chapter for the PL/M-286 code that implements this example of a 
memory manager. 


Protection Structure 


Where in the two-dimensional grid of protection offered by the iAPX 286 should the memory- 
management module lie? There are two approaches that offer different advantages: 


1. The module can be structured as privileged procedures that execute as part of every task that 
calls them. 


2. The module can execute as a separate task. 
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Figure 3-7. Splitting an Available Block of Memory 


GLOBAL PROCEDURES 


Placing the module’s segment descriptors in the GDT allows all tasks in the system to share the module 
yet requires only one copy of the module’s segments to be present in memory. This approach allows for 
fastest communication between the application and the memory manager. ) 


The procedures of the memory manager synchronize with the calling procedure (that is to say, the 
calling procedure waits until the memory-management procedure returns). However, more than one 
task can be executing the memory-management procedures at one time. This can be an advantage (as 
when there are multiple CPUs and the requests are for different regions of the memory space), but it 
requires synchronization of changes to space-management data structures (not shown in this example). 


Segments containing procedures and data structures internal to this most critical operating-system 
module should have the greatest protection possible. Because none of these procedures and data struc- 
tures are PUBLIC, no other modules can gain knowledge of the locations of data and procedures. This 
by itself, however, does not constitute positive protection from accidental or intentional snooping or 
destruction. The segments containing these procedures and data should have privilege level 0 (PL 0) 
so that the processor can prevent any access from less trusted procedures. 
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PRIOR FREE 
LINK.NEXT = 
CURR_AVLBL? 


NEXT FREE 
LINK.NEXT= 
CURR_AVLBL? 


The PUBLIC interface procedures ALLOCATE and FREE_SEG should execute at PL 0 to access 
the internal data structures and procedures, which are also at PL 0. ALLOCATE and FREE_SEG 
should have gates at PL 3, however, so that even least trusted application procedures can get the space 
they need for such purposes as dynamic data structures. 


SEPARATE TASK 


Another possible structure, not exemplified here, is to treat the memory-management module as a 
separate task. The iAPX 286 features for isolation of tasks provide the needed protection for the criti- 
cal memory-management structures and procedures. Within the memory-management task, privilege 
levels can be used to isolate the various internal procedures and data structures from one another. The 
memory-manager task can use a message passing mechanism such as that shown in Chapter 5 to receive 
requests and to pass segments to the requesting task. 


With the memory-manager executing as a separate task, serialization of requests for space is automatic, 
thereby eliminating the need for synchronization when modifying space-management structures. The 
separate-task approach is also advantageous when there is a need to have the requesting task wait until 
sufficient memory becomes available to fullfil a request. While one task is waiting, the memory manager 
can continue to service requests from other tasks. 
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In actual applications, the memory-management module may need to deal with such topics as 


e Different kinds of memory. The ALLOCATE procedure needs a parameter to specify (for example) 
slow versus fast memory, and each type of memory needs its own free-space list. 


¢ Multiprocessing. When multiple processors share some, but not all, of the available memory, the 
memory management module must know what memory addresses each processor can access. 
ALLOCATE must provide memory that is accessible to the processor that is running the calling 
task. You need to partition memory into areas so that all the addresses in a given area satisfy a 
common accessibility constraint. (The criteria for partitioning may also include memory types as 
mentioned previously.) Each area needs its own free-space list. 


e Dynamic deletion of memory. When a memory parity error occurs, the need for continued system 
operation may require deleting the affected block of memory from the available-space lists, so that 
it cannot cause more trouble. 


¢ Fixed-location segments. Often certain addresses of memory have specific uses, for example, video 
refresh buffers, and communication blocks for intelligent peripheral controllers. The memory manager 
must be aware of these areas and not use them for other purposes. Its interfaces must include the 
means for a task to request a specific special-purpose area. 


e Compaction. It can happen that no single free memory space is large enough to satisfy an 
ALLOCATE request, even though there is enough total free memory. Some memory-management 
subsystems call on a compaction algorithm in such cases. Whether implementation of a compaction 
algorithm is worthwhile depends primarily on the pattern of memory usage in a given application. 
In many applications, this situation arises only when memory is nearly full anyway; compaction in 
this case merely delays the inevitable by an insignificant time. If you do implement compaction, 
you may choose to associate with each allocated segment a pointer that helps the compaction 
algorithm find the descriptors for that segment. With a memory-management scheme such as that 
exemplified here, the boundary tags are the most convenient container for descriptor pointers. With 
descriptor pointers in place, the compaction algorithm need only follow the available-space lists to 
discover all the opportunities for compaction. 
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Figure 3-8. Possibilities for Combining Segments. 
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Figure 3-8. Possibilities for Combining Segments (Cont’d.) 
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system-ID 


PL/M=286 DEBUG Vx.y COMPILATION OF MODULE MEMORY 


OBJECT MODULE PLACED IN :F1:MEMORY.OBJ 
COMPILER INVOKED BY: :F3:PLM286.86 :F1:MEMORY.PLM CODE DEBUG 


Qo oon ss 


11 


12 


NN FN DF bh 


S$ PAGEWIDTH(71) TITLE('96@-501') INCLUDE (:F1:NUCSUB. PLM) 
S NOLIST 


MEMORY: DO; 


[BRR RR RK KEE ERR EERE KK EEA ERK RE KERR EKER KER ERERKEKEKREKEERER / 
/* Externals. */ 


POINT AT: PROCEDURE (SLOT, RIGHTS, PHYS _ADDR_PTR, LIMIT) 
oS EXTERNAL; 
DECLARE SLOT SELECTOR, RIGHTS BYTE, 
PHYS ADDR PTR POINTER, LIMIT WORD; 
END POINT _AT; 
NULLIFY: PROCEDURE (SLOT) EXTERNAL; 
DECLARE SLOT SELECTOR; 
END NULLIFY; 
GETSEGMENTBASE: PROCEDURE (SEL, BASE ADDR_PTR) EXTERNAL; 
DECLARE SEL SELECTOR, BASE ADDR_PTR POINTER; 
END GETSEGMENTBASE; 


LJ BRR RRR KKK EKER ERK KERR RRR ER ERE RE KREREREREKE RE REKRKEEKEREKRERE / 
/* Space-management definitions. iy A 


DECLARE PARAGRAPH LITERALLY '16'; 
/* To run under SIM286, all segments must have a base 
address equal to zero mod PARAGRAPH. This is not 
required when running on iAPX 286 hardware. weg 


DECLARE MEM_LINK LITERALLY 

"PADDING (8) BYTE, 

START DWORD, 
HI_TAG WORD, 
LO TAG WORD, 
PRIOR DWORD, 
NEXT DWORD, 
SIZE DWORD'; 

/* Base address of link descriptor is always PARAGRAPH 
less than address of PRIOR field. Address of PRIOR 
field is always @ mod PARAGRAPH. PRIOR, NEXT, and 
SIZE fields always point to a PRIOR - _ PARAGRAPH 
address. */ 


DECLARE TAGS SIZE LITERALLY "4'; 
/* The space used by both tag words */ 


DECLARE LINK LIMIT LITERALLY '27';. 
/* Limit used to construct descriptors for MEM_LINK */ 


DECLARE BLOCK MODULUS LITERALLY '32'; 
/* All memory blocks are an integral multiple of 
BLOCK_MODULUS in length. oo 


Figure 3-9. Code for Memory-Management Example 
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16 DECLARE NULL_PHYS_ADDR LITERALLY "O's; 

17 DECLARE USED LITERALLY 'l', 

FREE LITERALLY '@'; 
/* Values of boundary tags */ 
18 DECLARE OK _ - GLITERALLY '@', 
FAILED LITERALLY '8Q@@@H'; 
/* Values of exception codes */ 

19 DECLARE DWRIGHTS LITERALLY '92H' /* For manipulating 
space-management data structures, this module 
needs these rights parameters: Present, DPL=@, 
data segment, grow up, writable. x/ os 

AOI III III GIO TOIT OIC TI ATO AT 
Tn, ap OF Space-management data structures. */ 
20 DECLARE (FIRST AVLBL,LAST AVLBL,CURR_AVLBL) DWORD PUBLIC; 
/* Physical-address pointers to chain of available 
space. These always point to PRIOR - PARAGRAPH to 
avoid calculating base addresses for MEM_LINKs. a7, 
24 DECLARE SLOT A SELECTOR PUBLIC, 
WSLOT A WORD AT (@SLOT A) INITIAL (38H), /* 7 */ 
SLOT B SELECTOR PUBLIC, 
WSLOT_B WORD AT (@SLOT B) INITIAL (40H), /* 8 */ 
SLOT C SELECTOR PUBLIC, 
WSLOT_C WORD AT (@SLOT C) INITIAL (48H); /* 9 */ 
/* “Scratch" slots for addressing MEM LINKS. * / 
/* Be sure to reserve these slots with the Builder * / 
AIG CIOICI ICICI GCICICI GIGI SII ICII ICIS III CTOI IIIT / 
/* Round a size parameter upwards to next. greater * / 
/* or equal (N * BLOCK MODULUS) - TAGS SIZE for some N */ 
22 ROUND SIZE: PROCEDURE (A_PTR) PUBLIC REENTRANT; 
23 DECLARE A_PTR POINTER, 
ADDR BASED A PTR DWORD; 
24 ADDR =.BLOCK MODULUS 
* (((ADDR + TAGS SIZE - 1) / BLOCK _MODULUS) + 1) 
- TAGS SIZE; 

25 END ROUND SIZE; 

[RRR KERR RE RER KR E EEK RRR RHEE RE KERR EERE REREKEREE / 
/* Delink from available space list. : 

26 DELINKs: PROCEDURE (THIS SEL) REENTRANT; 

27 DECLARE THIS SEL SELECTOR, 

THIS LINK BASED THIS_SEL STRUCTURE (MEM_LINK) ; 

28 DECLARE PRIOR LINK BASED SLOT _C STRUCTURE (MEM LINK), 


Figure 3-9. Code for Memory-Management Example (Cont’d.) 


3-16 


121960-001 


ntal REAL MEMORY MANAGEMENT 


PL/M-286 COMPILER 960-501 date a) PAGE 3 


NEXT _ LINK BASED SLOT C STRUCTURE (MEM_LINK); 


29 2 IF THIS LINK.PRIOR = NULL PHYS ADDR 
/* This is the beg inning of the list. */ 
2 THEN FIRST AVLBL THIS LINK.NEXT ; 
31 2 ELSE DO; /* Update link from prior segment. */ 
3 CALL POINT _AT (SLOT _C, DWRIGHTS, 
@THIS LINK. PRIOR, LINK. LIMIT) ; 
3 PRIOR LINK.NEXT = THIS LINK. NEXT; ° 
34 3 END; 7 
2 IF THIS _LINK.NEXT = NULL PHYS ADDR 
/* This is the end of the list. */ 
2 THEN LAST AVLBL = THIS LINK. PRIOR; 
37 2 ELSE DO; /* Update link from next segment. */ 
3 CALL POINT AT(SLOT _C, DWRIGHTS, 
@THIS LINK.NEXT, LINK LIMIT); 


39 3 NEXT LINK.PRIOR = THIS LINK. PRIOR; 
46 3 END; . : 
41 2 END DELINK; 
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42 1 FIND FIRST _FIT: PROCEDURE (SIZE,BASE ADDR_PTR) 
. WORD REENTRANT ; 


43 2 DECLARE SIZE WORD, 
BASE ADDR_PTR POINTER, 
BASE ADDR BASED BASE ADDR_PTR DWORD; 


44 2 DECLARE CURR LINK BASED SLOT_A STRUCTURE (MEM_LINK), 
PHYS SIZE DWORD, 
SIZE DIFF DWORD, 
/* Boundary tag items */ 
BOUND _ADDR DWORD, 
BOUND _ MID BASED SLOT B STRUCTURE (MEM_LINK), 
BOUND HI BASED SLOT _B STRUCTURE (MEM_LINK); 


45 2 DECLARE TOP_LOOP LABEL; 
46 2 PHYS SIZE = SIZE; 
47 2 CALL ROUND _SIZE(@PHYS _SIZE); 
48 2 CALL POINT _AT (SLOT _A, ~ DWRIGHTS, 
@CURR ert LINK LIMIT); 
49 2 TOP LOOP: 7 
IF SLOT A = SELECTORSOF (NIL) /* Check for end of list */ 

50 2 THEN DO; | : 
51 3 IF FIRST AVLBL = NULL_PHYS_ ADDR 

/* The list is empty. */ 
52 THEN RETURN FAILED; 


3 
53 3 END; 
2 ELSE CALL POINT AT(SLOT_A, DWRIGHTS, 
. @FIRST AVLBL, LINK LIMIT); 
/* Continue from beginning of list. */ 


55 2 IF CURR LINK.SIZE < PHYS SIGE 
THEN /* This segment is “too small, so... */ 


Figure 3-9. Code for Memory-Management Example (Cont’d.) 
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56 2 DO; /* Look at next free segment in the list. */ 
57 3 CALL POINT AT(SLOT_A, DWRIGHTS, 
@CURR _LINK. NEXT, LINK LIMIT); 
58 3 If CURR_AVLBL = CURR _LINK. NEXT 
/* Have searched entire list without a hit. */ 
59 3 THEN DO; 
68 4 CALL NULLIFY(SLOT_ A); 
61 4 RETURN FAILED; 
62 4 END; 
63 3 GOTO TOP_LOOP; 
64 3 END; /* Segment too small. */ 
65 2 SIZE DIFF = CURR LINK. SIZE - PHYS _SIZE; 
/* Always a multiple of BLOCK MODULUS */ 
66 2 IF SIZE DIFF = @ 
67 2 THEN DO; /* This seanent is a close fit. */ 
68 3 CURR _AVLBL = CURR_LINK.NEXT; 
69 3 CALL DELINK (SLOT A); 
. /* Set lower boundary tag */ 
70 3 CURR _LINK.LO TAG = USED; 
/* Set upper boundary tag */ 
71 3 CALL GETSSEGMENTSBASE (SLOT A, @BOUND ADDR); 
72 (3 BASE_ADDR = BOUND ADDR; 7 7 
73, 3 BOUND ADDR = BOUND ADDR + CURR_LINK.SIZE + TAGS SIZE; 
74. 3 CALL POINT AT(SLOT B,DWRIGHTS,@BOUND ADDR,LINK LIMIT); 
1s «633 BOUND HI.HI TAG =USED; 
76 3 CALL NULLIFY(SLOT_A); CALL NULLIFY (SLOT B); 
78 3 BASE ADDR = BASE ADDR + PARAGRAPH; 
79 «3 RETURN OK; = 
8G 3 END; /* Close fit. */ 
81 2 ELSE DO; /* It will fit here with room to spare. */ 
82 3 CALL GETSSEGMENTSBASE (SLOT_A, @CURR_AVLBL); 
/* Set boundary tag at end of new segment. */ 
83 3 BOUND ADDR = CURR_AVLBL + CURR _LINK.SIZE + TAGS SIZE; 
84 3 CALL POINT: AT (SLOT _ B,DWRIGHTS, @BOUND | ADDR, LINK _LIMIT); 
85 3 BOUND HI.HI_ TAG = USED; 
/* Calculate starting address of the new segment. */ 
86 8963 BOUND ADDR = CURR_AVLBL + SIZE DIFF; 
87 3 BASE _ ADDR: = BOUND ADDR + PARAGRAPH; 
/* Set the boundary fields between the 2 segments. */ 
88 3 CALL POINT AT(SLOT_B,DWRIGHTS,@BOUND ADDR,LINK LIMIT); 
89 3 BOUND_MID.START = CURR_AVLBL; 
99 3 BOUND MID.HI_ TAG = FREE; 
91 3 BOUND MID.LO _TAG = USED; 
/* Change size of available segment, 
considering the 2 boundary tag words. */ 
92 3 CURR_LINK.SIZE = SIZE DIFF - TAGS SIZE; | 
93 3 CALL NULLIFY (SLOT _A); ~ CALL NULLIFY (SLOT _B); 
95 3 RETURN OK; 
96 3 END; /* Room to spare. */ 
97 2 END FIND FIRST FIT; 


SEJECT 


Figure 3-9. Code for Memory-Management Example (Cont’d.) 
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/* Place a segment into the available space list. */ 

98 5 RETURN SPACE: PROCEDURE(FREE SEG) REENTRANT; 
99 2 DECLARE FREE SEG © SELECTOR, 

FREE LINK BASED FREE SEG STRUCTURE (MEM_LINK); 
100 2 DECLARE CURR_LINK BASED SLOT_A STRUCTURE (MEM LINK), 

NEIBR_ADDR DWORD, 

NEIBR_LINK BASED SLOT _B STRUCTURE (MEM_LINK), 

FREE BASE DWORD, 

FREE SIZE DWORD, 

HI SIZE DWORD, 

NCASE BYTE, 


HI_ USED LITERALLY '@lH', 
LO USED LITERALLY '@2H'; 


1@1 2 CALL GETSSEGMENTSBASE (FREE SEG, @FREE BASE); 
192 2 FREE BASE = FREE BASE - PARAGRAPH; [*. point to tags */ 
1@3 2 FREE SIZE = GETSSEGMENTSLIMIT (FREE _SEG); 
194 2 FREE SIZE = FREE SIZE + Ly 
105 z CALL ~ ROUND __ SIZE (@FREE_ SIZE); 
. /* Determine which case. */ 
106 2 NCASE = @; 
/* Check higher naighuer. x / 
107 2 NEIBR_ ADDR = FREE BASE + FREE SIZE + TAGS SIZE; 
108 2 CALL POINT 1 ET (SLOT | B, DWRIGHTS, @NEIBR_. ADDR, LINK _LIMIT); 
1909 2 IF NEIBR _LINK. LO _TAG = USED THEN NCASE=NCASE OR HI _USED; 
lil 2 ELSE HI SIZE = NEIBR__ LINK.SIZE; /* Save */ 
/* Check lower neighbor. * / 
112 2 NEIBR_ADDR = FREE BASE; 
113 2 CALL POINT _AT(SLOT | B, DWRIGHTS, @NEIBR_ ADDR, LINK _LIMIT); 
114 2 IF NE IBR_ LINK. HI _TAG= USED THEN NCASE=NCASE OR LO _USED; 
/* Which segment should become the néw current one? */ 
116 2 ITF (NCASE AND LO USED) <>@ 
117 2 THEN CURR_AVLBL = FREE BASE; /* low neighbor used */ 
118 2 ELSE CURR _AVLBL = NEIBR_LINK.START; /* low free */ 
119 2 CALL POINT AT(SLOT _A,DWRIGHTS,@CURR_AVLBL,LINK LIMIT); 
/* Calculate size of new segment. */ 
120 IF (NCASE AND LO_USED) = LO_USED /* if low neibr used */ 


2 
121 (a THEN CURR _LINK. SIZE = @; 
L2Z2* 2 ELSE /* already contains size of low neighbor */ 
CURR LINK.SIZE = CURR_LINK. SIZE + TAGS _SIZE; 
123 2 IF (NCASE AND HI _USED) <> HI USED 


/* if high neighbor free */] 
124 2 THEN CURR_LINK. SIZE = CURR_LINK.SIZE+HI _SIZE+TAGS _SIZE; 
125 2 CURR_LINK. SIZE = CURR _LINK,. SIZE + FREE | SIZE; 


/* Set next and prior links in new segment. */ 


126 2 IF NCASE = 3 /* neither neighbor free */ 

127 2 THEN DO; /* insert at head of available list */ 
128 3 CURR LINK.PRIOR = NULL PHYS_ ADDR; 

129 3 CURR _LINK.NEXT = FIRST_AVLBL; 

134 3 END; 


Figure 3-9. Code for Memory-Management Example (Cont’d.) 
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ue 2 2 ELSE IF (NCASE AND HI _ USED) <> HI_USED 
/* if high neighbor free */ 
132 2 THEN DO; /* Dispose with high neighbor's links. */ 
/* Make selector for high neighbor. */ 
133 3 NEIBR_ADDR = FREE BASE + FREE SIZE + TAGS SIZE; 
134 3 CALL POINT _AT(SLOT_ B, DWRIGHTS,@NEIBR ADDR, , LINK _LIMIT); 
135 3 IF NCASE = @ /* both neighbors free */ 
THEN /* remove one from available list. */ 
136 CALL DELINK (SLOT _B); | 
137 ELSE /* Must be case 2. */ : 
DO /* Transfer links to new current. */; 
138 4 CURR_LINK.PRIOR = NEIBR_LINK. PRIOR; 
139 4 CURR LINK.NEXT = NEIBR LINK. NEXT; 
148 4 END; | 7 
141 3 END; /* disposing with high neighbor's links. */ 
142 2 IF (NCASE AND LO_USED) = LO USED 
/* if low neighbor used. */ 
143 2 THEN DO; /* Fix up links in prior and next segments. */ 
144 3 IF CURR_LINK.PRIOR = NULL PHYS _ADDR 
: THEN /* there is no prior */ 
145 3 FIRST AVLBL = CURR_AVLBL; | 
146 3 ELSE DO; /* fix up prior */. 
147 4 NEIBR_ADDR = CURR_LINK. PRIOR; . 
148 4 CALL POINT AT (SLOT _B, DWRIGHTS, @NEIBR_ ADDR, | 
LINK LIMIT); 
149 4 NEIBR. LINK. NEXT = CURR_AVLBL; 
15@ 4 END; 
A a 0 3 IF CURR_LINK.NEXT = NULL PHYS ADDR 
THEN /* there is no next */ © 
152 3 LAST AVLBL = CURR AVLBL; 
153 3 ELSE DO; /* fix up next */ 
154 4 NEIBR_ ADDR = CURR_LINK.NEXT; 
155 4 CALL POINT AT (SLOT _B, DWRIGHTS, @NEIBR_ ADDR, 
; LINK LIMIT); 
156 4 NEIBR_LINK.PRIOR = CURR_AVLBL; 
57 4 END; 
158 3 END; /* Fixing up links. */ 
/* Set tag words */ 
159 Z CURR LINK.LO TAG = FREE; 
/* Set START field in new current segment. */ 
160 2 NEIBR ADDR = CURR_AVLBL + CURR LINK.SIZE + TAGS _SIZE; 
161 2 CALL POINT _AT (SLOT | B,DWRIGHTS, @NEIBR_ BDU LINK _LIMIT); 
162 2 NEIBR LINK. START = CURR _AVLBL; 
163 2 NEIBR LINK. HI_ TAG = FREE; | 
164 2 CALL NULLIFY (SLOT _A); CALL NULLIFY (SLOT _B); 
166 2 END RETURN_SPACE; 


SEJECT 


Figure 3-9. Code for Memory-Management Example (Cont’d.) 
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ALLOCATE: PROCEDURE (SLOT, RIGHTS, SIZE, EXCEP_ PTR) 
PUBLIC REENTRANT; 


DECLARE SLOT SELECTOR, 
RIGHTS BYTE, 
SIZE WORD, 
EXCEP_ PTR POINTER, 
EXCEP BASED EXCEP_ PTR WORD; 


DECLARE BASE ADDR DWORD; 


IF OK <> FIND FIRST _FIT (SIZE, @BASE_ ADDR) 
THEN DO; 


EXCEP = FAILED; 
RETURN; 
END; 


CALL POINT AT (SLOT, RIGHTS, @BASE ADDR, SIZE-1); 
EXCEP = OK; | 
END ALLOCATE; 
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FREE SEG: PROCEDURE (SLOT, EXCEP_ PTR) PUBLIC REENTRANT; 


DECLARE SLOT SELECTOR, 
EXCEP PTR POINTER, 
EXCEP BASED EXCEP PTR WORD; 


CALL RETURN SPACE (SLOT); 
CALL NULLIFY (SLOT); 
EXCEP = OK; 

END FREE SEG; 
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END MEMORY; 


Figure 3-9. Code for Memory-Management Example (Cont’d.) 
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CHAPTER 4 
TASK MANAGEMENT 


The primary responsibility of an operating system is to allocate the processor to the executing tasks so 
that each task makes progress consistent with its role in the application. This chapter examines how 
the task-oriented features of the iAPX 286 hardware apply to conventional task-management concepts. 


HARDWARE TASK-MANAGEMENT FEATURES 


The operating system’s responsibility for managing a multitasking system is reduced by iAPX 286 
features for saving and restoring task state and switching between tasks. 


Storing Task State 


The state of a task (from the processor’s point of view) is the contents of the registers used by that 
task. The architecture of the iAPX 286 defines a special type of segment, the task state segment (TSS), 
for storing the 80286-related state of a task. Multitasking operating systems on any processor need to 
store similar information. The iAPX 286 requires merely that a specific format be used so that the 
CPU can store and restore task state automatically. Figure 4-1 illustrates a TSS and related hardware 
structures. 


The processor keeps the location of the TSS of the currently executing task in the task register. The 
task register has two parts: 


e The “visible” portion, which a task can access. This part contains a selector to the descriptor (in 
the GDT) for the current TSS. 


¢« The “invisible” portion, which tasks do not control. When the contents of the visible portion are 
changed, the processor loads the invisible portion with the base and limit values from the TSS 
descriptor indexed by the selector in the visible portion. 


There are two ways to change the task register: 


e By one of the task switching operations described later in this section. 


e By the LTR instruction. LTR is used to give the task register its initial value during system initial- 
ization. Only privilege-level 0 (PL-0) procedures can execute LTR. 


Because TSSs correspond one-to-one with tasks, the selector of a TSS uniquely identifies a task. The 
STR instruction reads the task register into a selector. Operating-system procedures can use STR to 
identify the calling task. The built-in variable TASK$SREGISTER gives PL/M-286 programs access 
to the task register. 


The items in the TSS fall into four classes: 
e Back link. Contains a selector to the TSS of the calling (or interrupted) task (if any). 


e LDT selector. Contains a selector to this task’s LDT. 
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Figure 4-1. Task State Segment and Register 


e Processor registers and flags. Used to store the processor state of the task. Note in particular the 
NT flag, which indicates when the BACK LINK contains a valid selector. 


* Initial stacks. Contain the initial SS and SP values to be used when a CALL transfers control to 
any of the higher PLs (0, 1, or 2). No stack pointer is needed in the TSS for the PL-3 stack because 
that stack is either the current stack (pointed to by the SS:SP fields) or is locatable via the chain 
of stack pointers in higher-level stacks. | = 
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The processor updates only the back link, the registers, and the flags as part of a task switching opera- 
tion. The processor merely reads the initial stack fields (during interlevel CALLs) and the LDT selec- 
tor (during a task switch). The operating system is responsible for initializing the stack and LDT fields. 
It must also upeate: the LDT selector before changing the LDT register. 


Switching Tasks 


Since a multitasking system typically has more tasks than it has processors to execute those tasks, 
there must be some provision for causing a processor to cease executing one task and begin executing 
another. The 80286 has several such mechanisms, each appropriate to different situations. All use 
ordinary JMP, CALL, INT, or IRET instructions. The destination operand determines whether a task 
switch occurs. Table 4-1 summarizes the operations and operands that cause switching of tasks. 


In PL/M-286, an indirect CALL statement to the selector of a TSS descriptor or task gate causes 
generation of an intertask CALL instruction. The WAIT$FORSINTERRUPT built-in procedure 
generates an IRET instruction. 


The operand of a CALL or JMP instruction is a pointer containing both selector and offset parts; in 
this case, the offset is not used, however. The selector portion may refer either to the descriptor of a 
TSS or to a task gate for a TSS. The result is the same in either case. The difference lies in the 
protection of access to the TSS. TSS descriptors, which may reside only in the GDT, normally have 
DPL set to zero to prevent unauthorized task switching by procedures outside the operating system. 
Task gates may reside in any descriptor table, giving task switching ability to procedures that have 
access to the gate. A task gate in an LDT gives task switching power only to that LDT’s task. A task 
gate in the IDT gives task switching power to interrupts. This reduces operating-system involvement in 
interrupt handling, and thereby reduces the time needed to respond to interrupts. 


The operating system normally uses a JMP instruction to a TSS descriptor to cause a task switch. A 
CALL instruction to a task gate in an LDT is useful for implementing coroutines. 


The IRET instruction exits from a nested task that is invoked by a CALL as well as from one invoked 
by an interrupt. (You cannot use the RET instruction to exit from a CALLed task; RET does not 
perform a task switch.) The NT (nested task) flag controls the function of the IRET instruction. When 
a CALL (or interrupt) causes a task switch, the processor sets the NT flag as the new task begins and 
fills the back-link of the new TSS with the selector of the calling task’s TSS. When the NT flag is set, 
the IRET instruction causes a task switch to the task whose TSS selector is stored in the back- link. 
The new task must be marked as epusy (type code = 3); otherwise an exception occurs. 


Table 4-1. Task Switching Operations 


Descriptor Descriptor 


| CALL, JMP,IRET JMP, tae 


CALL, JMP task gate _GDT, LDT 


INT instruction, 
external interrupt, 
exception 


task gate 
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If the processer, while executing an IRET instruction, finds the NT flag not set, this indicates a return 
to an interrupted procedure in the same task. Refer to Chapter 6. for details on interrupt procedures. 


For CALL and JMP instructions, success of a task switch operation depends on the type field of the 
TSS descriptor. If the type code is 1, denoting an available task, then the task switch proceeds. If the 
type code is 3, denoting a busy task, then an attempt to switch to the task causes an exception. A task 
is busy under either of these conditions: 


¢ The task is the currently executing task. 


¢ The task is on the chain of TSS back-links from the currently executing task. This prevents recur- 
sion of task invocations. A task should be restarted only by the the task that interrupts it or by the 
operating system after the task has been removed from the back-link chain. 


If the target task is not busy, the processor takes these steps in executing a task switch: 


e Saves all registers in current TSS 
¢ Loads TR with new TSS descriptor 
¢ Loads all registers and flags from new TSS (including LDT register) 


¢ If switch is due to CALL (or interrupt), sets NT flag and sets back-link in new TSS to point to 
_ previous TSS | | 


¢ If switch is due to JMP or IRET, changes the old task’s descriptor type code to< one, indicating that 
the task is no longer busy 


¢ Resumes new task where it left off (ie e., CS:IP from new TSS) 


Note that you cannot pass parameters by an intertask CALL. It is possible to share data peiween ne 
however. Chapter 5 takes up this subject. 


ROLE OF OPERATING SYSTEM IN TASK MANAGEMENT 


Task switching without operating-system involvement is possible (though not necessarily advisable) in 
static systems. Consider the following two application-driven scheduling strategies for static systems: 


1. A fixed sequence of tasks is defined, and each task, when ready to relinquish the processor, volun- 
tarily calls or jumps to the next task in sequence. Barring any errors, each task gets a share of 
processor time. 


2. All tasks in the system service external events. The interrupt mechanism of the iAPX 286, by 
means of interrupt tasks, causes task initiation in real-time response to those events. 


Strategy 1 is not viable in a highly protected system. Errors do-happen. An erroneous program might 
easily skip a task entirely. A programming error that causes a tight loop in one task would prevent all 
other tasks from being serviced. 


Strategy 2 can be adequate by itself for certain real-time systems with a static mix of tasks. Task 
switching by interrupt is usable in dynamic systems, too, but rarely do all tasks in a dynamic system 
deal exclusively with interrupts. Therefore, in dynamic systems, in highly protected systems, and in 
systems with tasks that do not provide real-time processing, the operating system may need to assist 
the processor with task switching. 
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State Model of Task Scheduling 


The role that the operating system must play in using the iAPX 286 task features is most conveniently 
expressed in terms of a state-transition model. To distinguish from the processing state of a task (as 
stored in the TSS), the term scheduling state is used here. Figure 4-2 illustrates the scheduling states 
that a task may assume and the events that may cause a change of state. 


A RUNNING task is the one that the processor is executing. A RUNNING task continues to execute 
until 7 | . | | aot ions: 


e It voluntarily gives up control because it needs to wait for some event, such as completion of an 
I/O operation, data from another program, or the end of a specific period of time. | ) 


¢ It is preempted, i.e., forced to give up control. The interrupt mechanism may cause preemption in 
order to execute an interrupt task, or the operating system may preempt periodically (via timer 
interrupt) to give another task a chance to receive its share of the processor’s attention. : 


A WAITING task may be waiting for any of several events: 


¢ Completion of a request to the OS for I/O 
¢ A signal from another task | 
e¢ Data from another task 


¢ The end of a time-delay period 


The READY state is really a special case of the WAITING state. A READY task is waiting for one 
specific event: the availability of a processor to execute it. A task becomes READY when first created. 
A WAITING task becomes READY upon occurrence of the event (or events) for which it is waiting. 
A RUNNING task becomes READY when preempted. 


STOP RESUME 


READY 
(AWAITING ig INITIATE 
DISPATCH PROCESSOR) | 


121960-22 


Figure 4-2. Scheduling State Transition Diagram 


4-5 121960-001 


intel TASK MANAGEMENT 


Usually, termination of a task is possible regardless of its scheduling state; therefore, this diagram does 
not illustrate the transition to “terminated” state. 


Interfacing with the Hardware Scheduler 


Many applications of the iAPX 286 need both software scheduling (by the operating system) and 
hardware scheduling (by the interrupt mechanism), but when two schedulers work with the same set 
of tasks, you must ensure that they work together harmoniously. Figure 4-3 illustrates the additional 
complexity of dual schedulers. 


Note that scheduling state under hardware scheduling is nearly analogous to scheduling state under 
software scheduling. The priority concept, often used in software scheduling, has its analog in the 
priority mechanism implemented by the interrupt controller. The priority of hardware- scheduled tasks 
relative to software-scheduled tasks is controlled by two factors: | 


¢ The CPU’s interrupt-enable flag (IF), and the instruction’ s CLI (which clears IF) and STI (which 
sets IF) 

¢ The 8259A Programmable Interrupt Controller, an LSI component that allows selective masking 
of interrupts so that software can prevent some external interrupts. 


When IF is set, all hardware-scheduled tasks whose interrupts are not masked out have higher priority 
than all software-scheduled tasks. When IF is reset, all hardware-scheduled tasks have lower priority 
than the currently executing task. Only the operating system (CPL <= IOPL) has the right to execute 
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Figure 4-3. Expanded Scheduling State Transition Diagram 
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CLI and STI instructions due to the significant effect that priority setting has on correct, overall 
system operation. | 


The ability for an interrupt handler to be an independent task not only protects the handler from the 
rest of the system but also permits greater flexibility in the kinds of functions an interrupt handler can 
perform. An interrupt handler that is a task can use operating system functions that might change its 
scheduling state. For example, if an interrupt handler requests the operating system to read a disk 
record, the operating system may change the interrupt handler task’s scheduling state from RUNNING 
to WAITING while the I/O operation takes place. (Other tasks may then execute in the meantime.) 
If the interrupt handler were a procedure instead of a task, it would be difficult to identify it separately 
from the task that it interrupted. 


The operating system must keep track of whether a task is attached to an interrupt (i.e., has a task 
gate in the IDT). Occurrence of an interrupt can at any time dispatch the task attached to the inter- 
rupt. This happens without intervention by the operating system; therefore, when a task calls on operat- 
ing system services, the operating system cannot assume that the calling task is the same as the latest 
software-scheduled task. 


An operating system can easily determine whether the current task is hardware or software scheduled 
if it associates with each task a Boolean that indicates whether the task was software-scheduled. The 
operating system must ensure that only one task at a time is so marked. The operating system can use 
the STR instruction to identify the current task. If the current task is not marked as software-scheduled, 
then the interrupt mechanism must have dispatched it. 


By knowing whether a task is attached to an interrupt, the operating system can 


e Avoid executing a task that is awaiting an interrupt. A software-scheduled task cannot respond to 
an interrupt. An exception occurs when an interrupt attempts to invoke a busy task. 


e Avoid preempting an executing interrupt task. That task should finish before software schedules 
another task. 


e Decide what action to take when an interrupt-dispatched task calls on operating-system scheduling 
services. Such action might be to mask off the interrupt or to place a gate for a counting task in the 
IDT to mark lost interrupts. | 


When the operating system changes a task from hardware scheduling to software scheduling, it must 
update the chain of tasks that threads through TSSs. Every hardware scheduled task has a link in its 
TSS to the TSS of the interrupted task. If the system’s interrupt structure permits nesting of inter- 
rupts, then the chain of interrupted tasks may be arbitrarily long. To change a task to software-scheduled 
mode, the operating system must take these actions (as figure 4-4 illustrates): 


¢ Reset the nested-task flag (NT) of the current task. 
° Nullify the back-link field in the current TSS (as insurance in case it is ever used). 


e Dispatch the prior task on the back-link chain. 


Changing Scheduling State 


In terms of the state model of scheduling, the operating system’s job is to effect transitions between 
scheduling states according to the expressed needs of individual tasks and of the application as a whole. 


In many cases, applications drive the scheduling activities of the operating system. Applications express 
their scheduling needs by calls to operating system functions that indirectly relate to scheduling. For 


4-7 121960-001 


TASK MANAGEMENT 


maonmga 


CURRENT 
SOFTWARE- 
SCHEDULED 
TASK 


poe 


BACK LINK 


BACK LINK 


CURRENTLY 
EXECUTING 
TASK 


FLAGS 


TSS 
NT=1 
BACK LINK 


Imi np 


FLAGS 


= CURRENT 
SOFTWARE- 
SCHEDULED 
TASK 


BACK LINK 


FLAGS 


BACK LINK 


HARDWARE-SCHEDULED TASKS 


SOFTWARE-SCHEDULED TASKS 


FLAGS 


TSS 
NT=0 
BACK LINK 


FLAGS 


TSS 
BACK LINK 
CURRENTLY 


EXECUTING 
TASK 


NT=0 


BACK LINK 


Figure 4-4. Changing Scheduling Mode 


4-8 


FLAGS 


TSS 
NT=0O 
BACK LINK 


121960-57 


121960-001 


intel TASK MANAGEMENT 


example, when an application calls the operating system to request receipt of a message from another 
task, the operating system determines whether a message is waiting for delivery. If no message is 
waiting, then the operating system must switch the task from RUNNING state to WAITING state. 
Later when another task calls the operating system to send a message to the waiting task, the operating 
system must change the task from WAITING state to READY state. In cases such as these, the 
operating system plays a bookkeeping role, simply keeping track of which tasks are waiting and associ- 
ating events with the correct waiting tasks. 


The operating system plays a much more significant role, however, when it determines which of the 
ready tasks to dispatch (the transition from READY state to RUNNING state) or when to preempt 
the task that is executing (the transition from RUNNING state to READY state). These decisions 
affect the overall performance of the system, both throughput and response to external events. _ 


POLICIES AND MECHANISMS 


Because of the difficulty of establishing an effective policy for dispatching and preemption decisions, 
it is desirable to clearly separate mechanisms from policies. The only control an operating system can 
exercise over tasks is deciding which task to execute and how long to let it run before changing to 
another task. The scheduling mechanisms must exert such control in a manner that the policies can 
adjust. For example, to control how long a task executes, the scheduler implements a mechanism for 
preempting the task after a certain time period has elapsed. The mechanism consists of an interval 
timer (such as Intel’s 8254 Programmable Interval Timer) that interrupts the executing task periodi- 
cally so that the operating system can determine whether the task has yet exceeded the time-slice 
allocated to it. The length of the time-slice is a variable that the policy layer can control. The policy 
layer sets the length of the time-slice to reflect the importance of the task. 


The separation of policy and mechanism applies as well to deciding which task to execute next. For 
example, the scheduling mechanism associates a priority number with each task. When changing tasks 
it always chooses the task with highest priority. The priority, however, is a variable, and the policy 
layer determines its value. 


For the policy layer to make reasonable decisions about scheduling, the mechanism layer may need to 
collect statistics about the run-time behavior of tasks, for example: 


* Elapsed time in the system 
* Total of actual time serviced by processor 


* Running average of actual length of time-slice 


(Note that interrupt-scheduled tasks subtract from the time allocated to software-scheduled tasks.) 


The privilege levels of the iAPX 286 architecture can support the separation between mechanisms and 
policies. The mechanisms belong to the kernel of the operating system, and as such they should be well 
tested, highly reliable, and not subject to frequent change; in other words, they are good candidates 
for PL 0. Policies, on the other hand, are subject to frequent change and, as a result, are less reliable. 
Running scheduling policies at PL 1 ensures that errors cannot corrupt kernel procedures. 
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‘SCHEDULING POLICIES 


The actual implementation of scheduling policies depends on the needs of the application and the 
behavior of the tasks in the system. Consider a simple policy that 7 


¢ Gives all tasks equal priority 
e Allocates the processor once to each task in turn 


° Allocates the same maximum. time-slot to each task 


Even this seemingly “fair” policy actually favors certain tasks over others. A task that frequently 
relinquishes the processor voluntarily (because, for example, it frequently has to wait for I/O) rarely 
uses the full time-slot. A “processor-bound” task (for example, a computational task that uses many 
instructions to accomplish its purpose but rarely does I/O), on the other hand, almost always uses the 
full time-slot, forcing the operating system to preempt it. Over a period of many time-slots, processor- 
bound tasks will receive much more attention from the processor than I/O-bound tasks. Whether this 
situation is desirable depends on the roles of the tasks in the application. 


Attempting to discriminate against processor-bound tasks by introducing a priority mechanism can 
result in different problems. Suppose all I/O-bound tasks have higher priority than all processor-bound 
tasks. At the end of a time-slice or when a task voluntarily gives up the processor, the scheduler switches 
to one of the higher-priority tasks if one is ready; if none is ready, it switches to one of the lower- 
priority tasks. The problem occurs when there is a such a number of I/O-bound tasks that at least one 
of them is always ready. In this case, the lower-priority, processor-bound tasks never execute. 


Many more scheduling policies than those outlined here are possible. The examples given merely illus- 
trate how important it is that the characteristics of the tasks in the system be known and that the 
policies match those characteristics. Refer to Coffman and Denning (see “External Literature” in the 
Preface) for a survey of these and other policies. 


Structuring Task Information 


If your operating system is to manipulate tasks efficiently, you must structure task-related information 
so that the operating system can get the information it needs as quickly as the application requires. 
The processor implements part of this structure through interlocking links in the GDT, LDT, and TSS. 
In addition to this structure, the operating system must deal with additional state information, which 
might include 


e The data-segment alias to the task’s LDT 

¢ The data-segment alias to the task’s TSS 

¢ Scheduling state 

¢ Scheduling parameters (for example, time-slice, priority) 


¢ Scheduling statistics (for example, total processor time used, average timce-slice used, expected 
running time) | 


e Links for queues of waiting and ready tasks 
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This additional state information is referred to here as the task database eens There are two common 
modes of access to the task database: | “ 


1. From within the current task to information about the current task. Most operating system services 
use this mode of access, including the scheduler’s time-slice interrupt procedure. 


2. From within the current task to information about other tasks. The scheduler uses this mode of 
access to find the next task to execute. 


ACCESS MODE 1 


Access mode 1 can be efficiently implemented via the GDT. All descriptors for the key segments 
relating to one task reside in adjacent GDT slots. If the operating system can locate one of these 
descriptors (as by using the STR instruction to obtain a selector to the current TSS), then it can locate 
any of the others by a simple addition or subtraction. Figure 4-5 suggests one possible way of organiz- 
ing the TDB. In this example the TDB is stored in a data structure called the task information block 
(TIB). 


In large systems you may need to minimize the number of GDT slots used for task information, so as: 
not to unduly limit either the number of tasks or the number of other descriptors that GDT can hold. 


LDT ALIAS 


TSS ALIAS 


121960-24 


Figure 4-5. Task Information Structure A 
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The example in figure 4-5 illustrates the general case in which all the pertinent information is in separate 
segments. This case uses five GDT slots. You can free one GDT slot by including the TSS within the 
TIB. The TIB descriptor can serve as the rs ac ~— for the TSS. Figure 4-6 illustrates such a 
configuration. 


Speed of access to the TDB is critical in some applications. Figure 4-7 shows another configuration of 
task information that helps improve access speed. Here the task’s stack segment for PL 0 contains both 
the TSS and the TIB. The advantage of this approach is that the TIB and the TSS can be addressed 
relative to the base address that the processor loads into SS when transferring control to a PL-O operating- 
system procedure. This eliminates the need for loading the DS or ES register to access the current 
task’s TSS or TIB and also frees a segment register for other use. In such a case, the SP portion of the 
TSS initial stack values for PL 0 is set to an offset beyond the TIB. In many applications it is still 
desirable for the GDT to hold.a a for the TIB so as to facilitate access to TIBs for tasks other 
than the current one. : 


ACCESS MODE 2 
When the scheduler is dispatching a different task, it needs quick access to the queues of waiting and 


ready tasks. If the links that implement these queues thread through the many segments that contain 
TIBs, the time needed to search and update the queues is extended by the time needed to load a 
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Figure 4-6. Task Information Structure B 
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_ Figure 4-7. Task Information Structure C 


segment register for each segment visited. This suggests that these queues all reside together in a 
separate scheduler queue segment. A pointer in each queue element can refer back to the correspond- 
ing task. Figure 4-8 illustrates such a structure. an. 


EXAMPLE OF A DISPATCHER | 


The process of changing a READY task to RUNNING state is known as “dispatching.” Figure 4-9 
shows a simple dispatching procedure. This procedure executes at PL 0 in the task that calls it. No 
call gate is provided, so only other operating system procedures can call DISPATCHER; for example, 
a procedure that switches the calling task to WAITING state, or a timer interrupt procedure that 
determines when to preempt the task that it interrupts. 


The DISPATCHER procedure is coded in ASM286 instead of PL/M-286 because it is more conveni- 
ent to code an indirect, intertask JMP instruction in ASM286. DISPATCHER makes two assumptions. 
about the rest of the operating system that justify the use of an intertask JMP instead of an intertask 
CALL: 


e A task can call operating system procedures that change it from RUNNING state, so a task does 
not need to execute an IRET for that purpose. 


e The operating system procedure that calls DISPATCHER may set the TSS back link so as to 
intercept an IRET if the task executes one. (When the operating system dispatches a task, it does 
not make sense for an IRET to return to the previously executing task. That task may, for example, 
be waiting for an event and not be ready to execute.) 
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Figure 4-8. Scheduler Queue Segment 
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SERIES-III iAPX286 MACRO ASSEMBLER V1.8 ASSEMBLY OF MODULE DISPATCHER 
:F5:DISP.OBJ 


OBJECT MODULE PLACED IN 


ASSEMBLER INVOKED BY: ASM286. 86 
LOC OBJ LINE 
¥ +] 
2 
3 
4 
5 
6 
a 7 
8 
-9604[] 9 
-8862{] 10 
-8904 []} 11 
12 
aie 13 
14 
9000 15 
16 
0909 CE8g4anag 1, 
G004 FA 18 
9005 9AGGG0---- E 19 
GG0A 3D000G 28 
G00D 7408 21 
22 
GO0F 8946FE 23 
GG12 C746FCORGD 24 
9017 FF6EFC 25 
26 
OG1A 27 
GG1A FB 28 
GG1B C9 29 
gG1C C3 30 
31 
32 
33 
34 
eet 35 
*** WARNING #160, LINE #35, 
36 
ASSEMBLY COMPLETE, 1 WARNING, 


:F5:DISP.ASM 


SOURCE 
$ TITLE ('968-593') 
NAME DISPATCHER 
EXTRN DEQUEUE READY: FAR 
PUBLIC DISPATCHER 
STACK STACKSEG 4 
TSS PTR EQU DWORD PTR [BP-4] 
TSS_ SEL EQU WORD PTR [BP-2] 
TSS OFFSET EQU WORD PTR [BP-4] 


NUCLEUS_CODE 
DISPATCHER PROC 


ENTER 
CLI 
CALL 
CMP 
JE 


MOV 
MOV 
JMP 
D_EXIT: 
STI 
LEAVE 
RET 
DISPATCHER ENDP 
NUCLEUS_CODE 


END 


NO ERRORS 


SEGMENT ER PUBLIC 
NEAR 


4,9 WE'LL FORM POINTER ON STACK 


ne 


RETURNS SELECTOR IN AX TO TSS 
SAME TASK? 
JUST RETURN 


DEQUEUE_READY 
AX,@ 
D_EXIT 


we Ne we 


FORM POINTER 
NOT USED ANYWAY 
TASK SWITCH 


TSS SEL, AX 
TSS OFFSET, @ 
TSS PTR: 


we Ne Ne 


WHEN THIS TASK EVENTUALLY REGAINS CONTROL, 
IT RESUMES EXECUTING HERE, SINCE THE OFFSET 
OF THIS INSTRUCTION WAS THE LATEST VALUE IN 
THE IP REGISTER FOR THIS TASK 


se we Ne Ne 


ENDS 


SEGMENT CONTAINS PRIVILEGED INSTRUCTIONS 


Figure 4-9. Dispatcher Example 
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CHAPTER 5 
DATA SHARING, ALIASING, aa ao UNCER rwere 


Even the simplest multitasking applications present a need for sharing data among tasks. In fact, 
examples presented in earlier chapters of this book have used data sharing, as in the example proce- 
dures in Chapter 3 that manipulate the free space list. For simplicity, these examples have avoided 
many of the implications of data sharing. However, sharing data among tasks is a complex activity 
that offers many opportunities for one task to cause another to fail. Therefore, for the protection of the 
system as a whole, the operating system must provide services that promote reliable data sharing. 


DATA-SHARING TECHNIQUES 


The architecture of the iAPX 286 allows segments to be shared among tasks through several tnecha- 
nisms. Each mechanism has different advantages and disadvantages, and requires different degrees of 
support from the operating system. fy 


Note that while the primary subject of this chapter i is data sharing, these segment-sharing prenuldues 
apply as well to code scement: a 


Sharing via the GDT 


All tasks in the system can access a segment whose descriptor resides in the GDT. This mode of sharing 
is especially useful for operating-system databases. Many operating- system procedures can be called 
from any task; they can access ayslem data ony if that data resides in pseements accessible to every 
task. 7 : ae os 


Normally, the system designer decides in advance which descriptors are to reside in the GDT and 
which in LDTs, and uses the Builder to install them in the appropriate descriptor table. The only 
support required from the operating system is to provide synchronization for access to the shared data. 


It is not always desirable to use GDT descriptors for sharing segments that only a few tasks use. A 
segment that has a descriptor in the GDT is accessible by all tasks, and exposing it to access from 
unrelated tasks may compromise the system’s protection goals. Deletion of GDT descriptors may have 
unknown effects, because it is diffucult to control usage of GDT said dae GDT epee may be needed 
for other purposes. 


Sharing via commen LDT 


When two (or more) tasks share most of the segments accessible to either one, then it is feasible for 
them to actually use that same LDT. Figure 5-1 illustrates how to share an LDT by placing the GDT 
selector of the LDT in the LDT field of the TSS of each task. 


LDT sharing is appropriate if the sharing tasks are designed to cooperate, and if you are willing to take 
the risk that a failure in one task might adversely affect the other tasks that use the same LDT. 
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Figure 5-1. Segment Sharing via Common LDT 


Sharing via Aliases. 


When tasks need to share simultaneously some, but not all, segments with selected other tasks, then 
aliasing is an appropriate method. As figure 2-15 illustrates, each task that shares a segment has a copy 
of the descriptor for that segment in its LDT. The term alias is used when there are multiple descrip- 
tors for a segment because each descriptor provides an alternate name for the segment. Not all the 
aliases for one segment need to be identical. Aliases may, for example, have different type or different 
access rights. 


Descriptor manipulation must be restricted to privilege level 0 (PL 0), but procedures at any privilege 
level can benefit from aliasing. Therefore, the operating system must provide high-level interfaces that 
cause creation and deletion of aliases. The operating system makes copies of descriptors for the shared 
segments and installs the copies in the LDTs of the sharing tasks (or possibly at other slots in the 
GDT). The operating system must strictly control which tasks may receive copies of which descriptors. 
The presence of multiple copies of a segment’s descriptor creates additional complexities for the 
operating system when it relocates, deletes, or otherwise modifies the segment. 


Beware of the confusion that can arise when tasks share data structures that contain selectors to alias 
descriptors. Task A may find a selector that points to a slot in Task B’s LDT. Nothing prevents Task 
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A from using the selector to reference its own LDT, but if it does so, the selector will likely refer to 
the wrong descriptor. One way to avoid this potential problem is by reserving the same slot position in 
the LDTs of all sharing tasks. 


ALIAS MANAGEMENT 


In any system that uses aliases for segment sharing, the operating system must ensure that all the 
aliases for a given segment remain consistent in spite of changes to the segment. The operating system 
may relocate a segment,. transfer it to or from secondary store, or delete the segment. If allowed to use 
a descriptor that had not been updated to reflect any of these changes, a task would fail and might 
cause other tasks to fail. Therefore, an operating system must implement a means to find and update 
all aliases for a segment when it changes any ¢ one of the aaNeS. 


Alias Database 


Figure 5-2 shows an example method for locating aliases. This method maintains a header block for 
each segment that has aliases. Pointers to all the aliases for that segment are linked to the header. As 
long as the entire list does not span more than one segment, the link fields (FIRST, LAST, NEXT, 
PRIOR, and HEADER) need only contain offsets. The doubly linked list shown here aids dynamic 
creation and deletion of alias pointers; for static systems, a singly linked list would suffice. 


In addition to the FIRST and LAST links, the list header contains that segment information that might 
change but that must remain consistent in all the aliases of a segment. Operating-system operations on 
segments demand that the segment base address and the present bit be consistent. Furthermore, any 
interrogation of the accessed bit for a segment demands that the accessed bits in all the aliases be 
ORed together. This example assumes that the operating system does not permit creation of aliases 
with differing limit or expansion direction. , : 


When a task that has a selector for an alias descriptor calls on operating system functions that make 
changes to segment attributes, those changes must be broadcast to all other aliases for the segment. 
Therefore, the operating system must have a means, given any descriptor, to find the alias list that 
includes that descriptor. Figure 5-3 illustrates one technique for doing this. Each descriptor table has 
a parallel table of pointers to alias list headers. The index in a selector that locates a descriptor in the 
descriptor table also locates a pointer in the parallel table. A descriptor that has no alias has a null 
entry in the corresponding position in the parallel table. For applications in which aliases are few, you 
can employ a hashing algorithm to reduce the number of entries in the parallel table. 


Alias Procedures 


Implementation of procedures for alias management for the 80286 is a straightforward application of 
list processing algorithms and therefore is not illustrated here. At a minimum, the operating ayeien 
should provide a CREATE _ALIAS procedure and a DELETE ALIAS procedure. | 


The operating system must enforce a correspondence between the existence of désciiptors for a segment 
and the existence of the segment itself. A segment must always have a descriptor, and an active 
descriptor must always point to a valid segment. A convenient way to enforce these rules is to permit 
only the DELETE_ALIAS procedure to call the segment FREE procedure. DELETE_ALIAS should 
cause deletion of a segment only when the last descriptor for the segment has been deleted. 


Geitns an alias is only the first step toward segment sharing. The CREATE_ALIAS procedure can 
only create an alias for a segment that is accessible to the task that calls CREATE_ALIAS. The next 
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Figure 5-2. Alias List 


step toward segment sharing is to pass the alias to another task. This subject is taken up in a later 
section of this chapter, ““Message Passing.” | | 


SYNCHRONIZATION 


Consider the example of a memory manager given in Chapter 3. While a memory management proce- 
dure manipulates the links that manage free space, there are instants when the data in the links is 
temporarily inconsistent (for example, the next-pointer in one segment has been set, but the previous- 
pointer in the next segment has not yet been updated). If the processor interrupts the task in which the 
memory-management procedure is running to run another task (or even another procedure in the same 
task) and if the new task (or procedure) calls the memory manager, then the the memory manager is 
likely to behave incorrectly. 


For the protection of the system, the operating system must prevent such forms of incorrect function 
in its own logic and must provide synchronization operations that enable application logic to avoid such 
failures as well. | 
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Figure 5-3. Identifying Alias List 


Low-Level Mutual Exclusion 


The most basic form of synchronization is control over critical sections. A critical section is a sequence 
of instructions that operates on shared resources in such a way that errors could result if another 
sequence of instructions operated on the same resources within the same time span. Any means that 
prevents any two critical sections from overlapping in time would prevent such errors. In a single- 
processor system, only an interrupt can cause the operations of one critical section to interleave with 
those of another. Disabling interrupts provides the necessary mutual exclusion. | 


Procedures that disable interrupts to provide mutual exclusion must adhere to certain rules: 


¢ Determine the maximum permissible delay for servicing an interrupt, and do not code a critical 
section that takes more time. | 


e Avoid causing a fault that might keep interrupts disabled for a longer time than permissible. 
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« Do not nest critical sections; there is only one interrupt flag. 


¢ Do not switch tasks; doing so may enable interrupts. 


Disabling interrupts as a means to provide mutual exclusion is not a generally applicable technique. 
The rules above are too restrictive for many situations, and the CLI and STI instructions for disabling 
and enabling interrupts are restricted to procedures whose CPL does not numerically exceed IOPL. 
An operating system can, however, use this technique for its own short-term, high-speed exclusion 
requirements and as the basis for more general synchronization operations. 7 


High-Level Mutual Exclusion 


A more generally applicable form of mutual exclusion must permit interleaving Cr interrupts and 
software task switching) of unrelated critical sections. 


SEMABHORE t DATA STRUCTURE 


‘Figure 5-4 illustrates an example data structure for implementing a general purpose form of control 
over Critical sections: binary semaphores. The semaphore structure consists of a counter and a queue. 
Every shared resource subject to the effects of contention needs one Sia Aas structure to provide 
mua exclusion for the tasks using the resource. 


The value of the counter is one minus the number of tasks waiting at the semaphore. A value of one 
indicates that the semaphore is available; a value of zero indicates the the semaphore has been acquired 
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Figure 5-4. Semaphore Structure 
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but no other tasks are waiting for the semaphore; a negative value indicates that some tasks are queued, 
waiting for the semaphore to be released. The queue is circular so that the pointer to the pose of the 
queue also identifies the tail of the queue. | ; 


Semaphore structures may be stored individually in separate segments or may be stored together in 
one or more segments. In the latter case the operating system must provide a means for identifying 
individual semaphores within a segment. Storing the semaphore counter in a segment by itself yields 
two important advantages: | 


¢ The processor can individually protect each semaphore. 
e The selector of the descriptor for the gi cts seement serves as a convenient identifier for the 


semaphore. - 


Semaphore structures are sensitive data that must be cloistered behind the level 0 protection wall. 
Semaphores may reside either in the GDT or in the LDTs of the tasks that use them. The same 
considerations apply as for shared data segments. ee 


SEMAPHORE-MANAGEMENT PROCEDURES 
The minimum set of operating-system procedures niet to use semaphores includes 


¢ WAIT_SEMAPHORE to acquire a semaphore if it is not t already agree 
e SIGNAL_SEMAPHORE to signal departure from a critical section 


Dynamic systems may also need to define semaphores dynamically with procedures such as 


. CREATE_SEMAPHORE for setting up a new semaphore structure - 
° DELETE_SEMAPHORE to eliminate a semaphore structure that is no longer needed 


The operating system’s responsibilities in managing binary semaphores include 


e Ensuring that no more than one task holds a semaphore 


. When a task requests a semaphore that has not been signalled, placing the task ina waiting queue, 
_ and dispatching another task 7 


« When a task signals a semaphore, awakening the next task in the waiting queue for that semaphore 
and placing it in the ready queue : : 


. Preventing or being prepared to handle any deadlock that may result from using semaphores 
Figure 5-5 shows simple examples of how to use a low-level synchronization technique to implement’ 
WAIT_SEMAPHORE and SIGNAL_SEMAPHORE procedures. These procedures must run at 


PL 0 to access the semaphore structures. With segment descriptors in the GDT and with call gates at. 
PL 3, any procedure in the system can.call these synchronization primitives. 
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PL/M-286 COMPILER 960-504 date PAGE 1 


‘system-ID 


PL/M-286 Vx.y COMPILATION OF MODULE SEMAPH 


OBJECT MODULE PLACED IN :F1:SEMAPH.OBJ | 
COMPILER INVOKED BY: PLM286.86 :F1:SEMAPH.PLM DEBUG 


190 ON 


18 


ll 


12 


13 


NF 


NN Ee 


WWWWHONNDND.,. 


S PAGEWIDTH(71) TITLE('96@-504') INCLUDE (:F1:NUCSUB. PLM) 
S NOLIST . . 


SEMAPH: DO; 


JOO III III IGG IOI CI CIGI TODOS IIIT II 7 se 
/* ' Externals * / 


DISPATCHER: PROCEDURE EXTERNAL; 
END DISPATCHER; 


ENQUEUE WAIT: PROCEDURE(QUEUE ID) EXTERNAL; 
DECLARE QUEUE ID SELECTOR; 
END ENQUEUE WAIT; 


DEQUEUE WAIT: PROCEDURE (QUEUE_ID,EXCEP P) EXTERNAL; 
DECLARE QUEUE ID SELECTOR, EXCEP_P POINTER; 


END DEQUEUE WAIT; 


[BRR KKH HK RRR KKK KKK RIKKI KKK IR HK IKE KIKI KHER K HEE / 
[* Semaphore Data Structures an 4 


DECLARE SEMAPHORMAT LITERALLY 
'FILLER (2) WORD, 
COUNTER.  WORD'; 


DECLARE OK LITERALLY '@'; 


III III GIOII IIIT III III I IIIA 7 
/* Test a semaphore; wait if not set */ 


WAIT SEMAPHORE: PROCEDURE (SEMAPH_ID, EXCEP P) 
“ PUBLIC REENTRANT; | 


DECLARE SEMAPH ID SELECTOR, 
SEMAPH BASED SEMAPH_ ID STRUCTURE (SEMAPHORMAT) ; 


DECLARE EXCEP_P POINTER, 
EXCEP BASED EXCEP_P WORD; 


DISABLE; 
S EMAPH .COUNTER=S EMAPH.COUNTER-1; 
IF ZERO /* Test the zero flag. */-° 
THEN /* Semaphore was set. */ DO; 
ENABLE; 
EXCEP=0K; 
RETURN; 
END; 


_/* Semaphore is not set; this task must wait. */ 
CALL ENQUEUE_WAIT (SEMAPH ID); 


Figure 5-5. Semaphore Example 
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PL/M-286 COMPILER 960-504 date PAGE 2 

24 2 ENABLE; 
25 2 CALL DISPATCHER; 
262 END WAIT SEMAPHORE; 

[BR RR RRR KKK KIRK REE HK KKK KKK IKK KER KEKE KKEEKEKEKKKKEKKEKREEKK / 

7 Set a Semaphore */ 
27 1 SIGNAL SEMAPHORE: PROCEDURE (SEMAPH ID, EXCEP_P) 

PUBLIC REENTRANT; 
28 2 DECLARE SEMAPH_ID SELECTOR, 
? SEMAPH BASED SEMAPH ID STRUCTURE (SEMAPHORMAT) ; 
29 2 DECLARE EXCEP_P POINTER, 
EXCEP BASED EXCEP_P WORD; 

3802 DISABLE; 
31 462 S EMAPH . COUNTER=SEMAPH.COUNTER#+1; _ 
32 2 IF NOT (ZERO OR SIGN) /* Test flags. */ 
33 2 THEN /* No one is waiting at this semaphore. */ DO; 
34 3 ENABLE; 
35 3 EXCEP=OK; 
363 RETURN; 
37 3 END; 


/* Someone is waiting at this semaphore. i 


38 2 CALL DEQUEUE_WAIT (SEMAPH_ID, @EXCEP); 
39 2 ENABLE; 7 
40 2 CALL DISPATCHER; 
41 2 EXCEP=OK; 
42 2 END SIGNAL SEMAPHORE; 
AOI IOI OCI IOI III IIIT IOI III IIIT TOTO TOSI 
43 1 END SEMAPH; 


MODULE INFORMATION: 


CODE AREA SIZE 


= 98084H = £=132D 
CONSTANT AREA SIZE = 9@@80H 8D 
VARIABLE AREA SIZE = @800H 8D 
MAXIMUM STACK SIZE = @816H 16D 


187 LINES READ 

@ PROGRAM WARNINGS | 

@ PROGRAM ERRORS 
DICTIONARY SUMMARY: 

91KB MEMORY AVAILABLE 

4KB MEMORY USED (43%) 

@KB DISK SPACE USED 


END OF PL/M-286 COMPILATION 


- Figure 5-5. Semaphore Example (Cont’d.) 
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OTHER FORMS OF SYNCHRONIZATION 
You may wish to implement other forms of synchronization; for example: 


¢ Conditional variation of WAIT.SEMAPHORE that does not force a task to wait when the semaphore 
has not been signalled. 


e Timed waiting, so that a task can be awakened if the semaphore i is not signalled within a reasonable 
time. (This helps guard against deadlocks.) 


e An extension of the semaphore concept known as a region. A region is similar to a semaphore except 
that only the task that acquires a region can release (signal) it, and a task that holds a region cannot 
be suspended. | | 


MESSAGE PASSING 


Message passing is a general purpose means for transferring data from the address space of one task 
to the address space of another, cooperating task. There are two aspects to the technique: 


e Transferring data from a segment in one task’s address space into a segment in the receiving task’s 
space 


e Transferring a Sephient from one task’s space into another’s 


The first case is suitable for passing relatively small amounts of data, such as parameters, information 
describing events, etc. The second case has two primary applications: 


¢ For transferring large “consumable resources” such as I/O buffers 


¢ For transferring aliases that implement the previously described method of “sharing via aliases” 


When an alias is passed as part of a message, the operating system installs the alias in a descriptor- 
table slot determined by the receiving task. 


Message-Passing Example 


Figure 5-6 shows an example data structure for implementing a simple form of message passing. This 
structure defines a mailbox, a queue of tasks waiting for messages from the mailbox, and a queue of 
undelivered messages. The system may contain one mailbox for every communication channel between 
tasks. For simplicity, this example assumes that the format of messages for all mailboxes 1 is the same, 
consisting of a fixed-length data item and two descriptors. - 


If each mailbox resides in a unique segment, then these advantages result: 


e Mailboxes are protected from operations on other mailboxes. 

e A selector can serve as the identifier of a mailbox. 

Only the sending and receiving tasks need access to a mailbox; therefore, the appropriate tables for 
descriptors for mailbox segments are the LDTs of each of the tasks that share a mailbox. All tasks can 


share a global mailbox, however, if its descriptor is in the GDT. The DPL for all mailbox segments 
should be zero to prevent procedures outside the operating system from interfering with message passing. 


Mailboxes require at least two procedures: SEND_MESSAGE and RECEIVE_MESSAGE. Figure 
5-7 shows examples of these procedures. Both procedures must run at PL 0 to access level-O0 mailbox 
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Figure 5-6. Mailbox Structure 
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segments. If there are call gates in the GDT at PL 3, then these procedures are accessible to all other 
procedures in the system. 


SEND_MESSAGE fills a message with the specified data and descriptors, removes the descriptors 
from the descriptor table, and links the message at the tail of the message queue. If a task is waiting 
at the mailbox, SEND_MESSAGE causes it to be linked into the ready queue so that it will find the 
message the next time it is scheduled to run. 


If RECEIVE_MESSAGE finds no messages waiting at the mailbox, then it links-the task into a waiting 
queue. The task queue threads through the task database. The task will continue executing when another 
task sends a message to the mailbox. If (or when) a message is waiting, RECEIVE_MESSAGE writes 
the data portion of the message at a specified location in the receiving task’s space and installs the 
descriptor portion in specified slots in one of the receiving task’s descriptor tables (GDT or LDT). 


These examples do not include management of space and queues for messages because conventional 
algorithms apply. External procedures GET_MSG_SPACE, ENQUEUE_MESSAGE, 
DEQUEUE_MESSAGE, and FREE_MSG_SPACE provide these functions. 


Special handling is eerie to nceammodale the fact that a descriptor in a message is temporarily not 
in any descriptor table. There are two cases to consider: 


e The descriptor is the sole descriptor for the segment. In this case, no changes can be made to the 
segment because it is temporarily inaccessible. You should take care that no failure in the commu- 
nication process causes the CESCHDLOF to become lost. A memory area without a descriptor cannot 
be freed. | . ish. 


e The descriptor is an alias or one of a ideccteiet for the same eeenty Since the segment 
is (presumably) accessible via the other aliases, it is possible for some task to request some operation 
on the segment during the time the descriptor in the message is absent from any descriptor table. 
Normally, the operating system updates all aliases when it makes any major changes to a segment 
(for example, relocation or swapping to secondary store). This is not possible (given the aliasing 
scheme previously presented in this chapter) when the alias is not in a descriptor table. To solve the 
problem, this example assumes there are two procedures: 


a. DISABLE_ALIAS_PTR that marks the alias list element to indicate to the alias manager that 
the alias is in a mailbox 


b. FIX_ALIAS_PTR that, when the message is delivered, updates the alias pointer with the new 
location of the alias and with any segment information that may have changed while the alias 
was absent from the alias list. 


Dynamic systems may need to create and delete mailboxes dynamically. The only difficulty in creating 
a mailbox is ensuring that no task uses it while it is being constructed. (The next section considers this 
problem.) To delete a mailbox the operating system must awaken any tasks that are waiting for messages, 
delete any descriptors (aliases) that reside in undelivered messages, and delete the undelivered messages 
themselves. 7 


The operating system may, as part of the process of task creation, give each task at least one mailbox. 
If the mailbox feature is the only means of passing aliases among tasks, a task cannot receive an alias 
for a mailbox unless it already has a mailbox. Some operating system designs may require every task 
to have a mailbox for such purposes as receiving memory segments from the memory-allocation module. 


5-12 121960-001 


intel 


DATA SHARING, ALIASING, AND SYNCHRONIZATION 


PL/M-286 COMPILER 969-598 date PAGE 1 


system-ID 


PL/M-286 Vx.y COMPILATION OF MODULE MAILBOX 


OBJECT MODULE PLACED IN :F1:MBOX.OBJ 
COMPILER INVOKED BY: PLM286.86 :F1l:MBOX.PLM DEBUG 


Ul md W 


NN Fe 


NON Fe 


S$ PAGEWIDTH(71) TITLE('968-508') INCLUDE (:F1:NUCSUB. PLM) 
S$ NOLIST . | 


MAILBOX: DO; 


[III IIIT IIIT III ITO IK / 
/* | Definitions * / 


DECLARE FAILED LITERALLY '8@@0@H', 
OK LITERALLY '@'; 


[BRK KKK RIKER KR RIK RRR REAKK ER RIK KK RK KEK / 
f* Externals * / 


NULLIFY: PROCEDURE (SLOT) EXTERNAL; 
DECLARE SLOT SELECTOR; — 
END NULLIFY; 


STORE DESCR: PROCEDURE(SLOT,PTR) EXTERNAL; 
DECLARE SLOT SELECTOR, 

PTR POINTER; 
END STORE_DESCR; 


LOAD _DESCR: PROCEDURE(PTR,SLOT) EXTERNAL; 
DECLARE PTR POINTER, 

SLOT SELECTOR; 
END LOAD_DESCR; 7 


DISPATCHER: PROCEDURE EXTERNAL; 
END DISPATCHER; 


ENQUEUE WAIT: PROCEDURE (QUEUE_ID) EXTERNAL; 
DECLARE QUEUE ID SELECTOR; 
END ENQUEUE WAIT; 


DEQUEUE WAIT: PROCEDURE (QUEUE_ID, EXCEP_P) EXTERNAL; 
DECLARE QUEUE ID SELECTOR, EXCEP P POINTER; 
END DEQUEUE WAIT; 


DISABLE ALIAS PTR: PROCEDURE(SLOT) EXTERNAL; 
DECLARE SLOT SELECTOR; 
END DISABLE ALIAS PTR; 


FIX ALIAS PTR! PROCEDURE(ALIAS LIST _ID) EXTERNAL; 
DECLARE ALIAS LIST ID POINTER; 
END FIX ALIAS PTR; 
GET MSG SPACE: PROCEDURE(BOX _ID,MSG P_P,EXCEP P) EXTERNAL; 


DECLARE BOX_ID SELECTOR, (MSG P_P, EXCEP P) POINTER; 
END GET MSG SPACE; 


Figure 5-7. Example of Mailbox Procedures 
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29 1 FREE MSG SPACE: PROCEDURE (BOX __ rD; MSG _PTR) EXTERNAL; 
30 2 DECLARE BOX_ID SELECTOR, 
MSG PTR POINTER; 
31 2 END FREE MSG SPACE; 
32 1 e ENQUEUE MESSAGE: PROCEDURE (BOX. ID, MSG PTR) EXTERNAL; 
33 2 DECLARE BOX ID SELECTOR, 
MSG PTR’ POINTER; 
34 Z END ENQUEUE_ MESSAGE; 
35: OL DEQUEUE MESSAGE: BROCEDURE (BOX_ID, MSG_P_P, EXCEP_P) 
| | EXTERNAL; 
36 2 DECLARE BOX_ID SELECTOR, (MSG PP, EXCEP _P) POINTER; 
37 2 END DEQUEUE MESSAGE; 
[8 RRR RRO TORII III TOTO I IOI IO TOK IOI IO ICR / 
f* Mailbox Data Structures * / 
38 1 DECLARE MDATA SIZE LITERALLY '46'; 
39 1 DECLARE MESSAGE FORMAT LITERALLY 
*"MDATA (MDATA_SIZE) BYTE, 
DESCRI1 (4) WORD, 
DESCR2 (4) _ WORD';, 
[DIIGO IIIT III III III III IOI IIIA IK / 
/* Send Message via Mailbox */ 
40 1 SEND MESSAGE: PROCEDURE (BOX_ID, MDATA_PTR, SLOTI, SLOT2, 
EXCEP_P) PUBLIC REENTRANT; 
41 2 | DECLARE BOX_ID SELECTOR, 
MDATA PTR POINTER, 
(SLOT1, SLOT2) SELECTOR; 
4g DB DECLARE EXCEP_P -- POINTER, 
EXCEP BASED EXCEP_P WORD; 
43 2 DECLARE MSG PTR POINTER, 
MESSAGE BASED MSG _ PTR STRUCTURE 
(MESSAGE _FORMAT) ; | 
44 2 CALL GET MSG SPACE (BOX_ ID; @Msc PTR, @EXCEP) ; 
45 2 IF EXCEP=FAILED THEN ye the box is full of messages x / 
46 2 DO; 
47 3 CALL DISPATCHER; 
48 3 RETURN; 
49 3 END; 
/* The next statement will cause an exception if the 
segment containing the data is not present. 
Therefore interrupts are enabled. ald 
5@ 2 CALL MOVB (MDATA_ PTR, @MESSAGE.MDATA, MDATA SIZE); 
51 2 IF SLOT1=SELECTORSOF (NIL) . ; < 
52 2 THEN MESSAGE.DESCR1(2)=8; /* Mark as null */ 
53 2 ELSE DO; 
54 3 CALL STORE DESCR(SLOTI, @MESSACE. DESCR1); 
55 3 CALL DISABLE ALIAS PTR(SLOT1L); 


Figure 5-7. Example of Mailbox Procedures (Cont’d.) 
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56 3 CALL NULLIFY(SLOT1); 
57 3 END; . 
58 2 IF SLOT2= S ELEC TORSOF (NIL) 
59 2 THEN MESSAGE.DESCR2(2)=0; /* Mark as null */ 
60 2 ELSE DO; 
61 3 CALL STORE DESCR(SLOT2,@MESSAGE.DESCR2) ; 
62 3 CALL DISABLE ALIAS rae SuOTe a 
63 3 CALL NULLIFY (SLOT2) ; 
64 3 END; 
65 2 DISABLE; 
66 2 CALL ENQUEUE MESSAGE (BOX_ID, MSG PTR); 
67 2 CALL DEQUEUE _ WAIT (BOX_ ID, ', @EXCEP) 3 
68 2 ENABLE; 
69 2 CALL DISPATCHER; 
79 2 RETURN; 
7 2 END SEND_ MESSAGE; 
[BR RRR RRR K KERR RK KK RR KKRRIKR KR KKRKRKKK KEKE RK KEK KERR K REE / 
/* Receive Message from Mailbox */ 
72221 RECEIVE MESSAGE: PROCEDURE (BOX_ID, MDATA_PTR, SLOT1, 
SLOT2, EXCEP_ P) PUBLIC REENTRANT; 
73 2 DECLARE BOX_ID SELECTOR, 
MDATA_ PTR POINTER, 
(SLOT1, SLOT2) SELECTOR; 
74 «2 DECLARE EXCEP P POINTER, 
EXCEP BASED EXCEP P WORD; 
i 
75 2 DECLARE MSG PTR POINTER, : 
MESSAGE BASED MSG PTR STRUCTURE 
(MESSAGE FORMAT); 
76 2 CHECK MAIL: 


DISABLE; 


77 2 CALL DEQUEUE MESSAGE (BOX_ ID, @MSG PTR, @EXCEP); 
78 2 IF EXCEP=FAILED THEN /* No mail today */ 

T9 2 DO; 

80 3 CALL ENQUEUE WAIT (BOX ID); 

81 3 ENABLE; 

82 3 CALL DISPATCHER; 

83 3 GOTO CHECK MAIL; 

84 3 END; 

85 2 ENABLE; 


/* Next statement may cause exception. */ 

CALL MOVB(@MESSAGE.MDATA, MDATA PLR MDATA _SIZE); 

IF MESSAGE.DESCRI1 (2) <>@ /* Test for null descriptor */ 
THEN DO; 
CALL LOAD DESCR(@MESSAGE.DESCRI, SLOT1); 
CALL FIX ALIAS PTR(@MESSAGE.DESCR1); 


\o 
Q 
WNHNWWWNNND 


91 END; 

92 -IF MESSAGE.DESCR2(2)<>@ /* Test for null descriptor */ 
93 THEN DO; | | 

94 CALL LOAD DESCR(@MESSAGE.DESCR2, SLOT 2) ; 


Figure 5-7. Example of Mailbox Procedures (Cont’d.) 
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CALL FIX _ALIAS_PTR(@MESSAGE.DESCR2); 

END; | | 
CALL FREE MSG SPACE(BOX_ID,@MESSAGE) ; 
EXCEP=OK; | 


END RECEIVE MESSAGE; 


[BR RRR IRR IK IO RIOR IR ROR I TOI IR TOR TORI TOI TORK IRR RIKI IK / 


END MAILBOX; 


MODULE INFORMATION: 


CODE AREA SIZE 
CONSTANT AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
193 LINES READ 

@ PROGRAM WARNINGS 
@ PROGRAM .ERRORS 


DICTIONARY SUMMARY: 
91KB MEMORY AVAILABLE 
6KB MEMORY USED (6%) 
@KB DISK SPACE USED 


END OF PL/M-286 COMPILATION 


Figure 5-7. Example of Mailbox Procedures (Cont’d.) 


Variations on the Mailbox Theme 
Some of the features appropriate for semaphores are also appropriate for mailboxes, namely: 


¢ Conditional receive 


e Timed wait 


For applications in which speed is not the overriding goal, mailboxes can substitute for semaphores. A 
mailbox is analogous to a semaphore, with the counter of a semaphore corresponding to the number of 
messages waiting at a mailbox. A mailbox with null messages is identical in function to a semaphore. 


Most applications that use mailboxes require different message formats (different data size, different 
number of descriptors) for different communication channels. With dynamically created mailboxes, 
message format may be defined by parameters to the creation procedure, encoded in the mailbox, and 
interpreted by the SEND_MESSAGE and RECEIVE_MESSAGE procedures. 
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Systems that implement “pipes” as a form of intertask communication can call mailbox procedures 
from the device drivers for the pipes. 


It is possible to use mailboxes as the sole means of interface between applications and operating system. 
For example, the operating system has one mailbox through which it receives service requests from all 
applications; each task has a mailbox through which it receives responses from the operating system. 
To get more memory, a task would send a memory request message to the operating system; the operat- 
ing system would return a message containing an alias for the allocated memory segment and install 
the alias in the task’s LDT. The advantage is simplicity. Only two global gates are needed: one for 
SEND_MESSAGE and one for RECEIVE_MESSAGE. A task can wait for only one purpose: for a 
message from a mailbox. The disadvantage is inefficiency. Any implementation of mailboxes is bound 
to be less efficient than the interlevel CALL instruction normally used to communicate with an operating 
system. 


All of these forms of message-passing can use the primitive synchronization and descriptor-manipulation | 
techniques illustrated in this section.B 
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CHAPTER 6 
SIGNALS AND INTERRUPTS. 


Interrupts are a mechanism long used in single-task microprocessors for reacting quickly to external 
events. In the multitasking architecture of the iAPX 286, each task may have the same needs for 
information about external events as the one task in a single-task system. In a multitasking system, 
several generalizations of interrupts are useful: | | 


¢ Some tasks may do nothing but service a specific external event. While the task waits for an event 
to occur, the processor can service other tasks. 


e Information about an external event must be routed to the correct task. 


e Events external to a task may include events occurring in other tasks ¢ as well as events external to 
the processor. 


«The ability to selectively ignore events must then extend to those events occurring in other dere 


e Each task can benefit from a vector table to automatically route information aout events to the 
correct handler procedures within the task. 


e Scheduling of tasks that service events must be coordinated with the software scheduler, while 
retaining the ability to respond rapidly to events. 


The 80286 implements some of these generalizations of interrupts onto the multitasking environment, 
but the operating system has responsibility for others. Not all are relevant to every application of the 
80286. 


INTERRUPT FEATURES OF THE iAPX 286 ARCHITECTURE 


The iAPX 286 architecture includes a number of features that work together to enable efficient response 
to events. , | 


Vectoring 


The processor associates each event with an identifying number in the range 0-255. The processor 
recognizes three classes of events: 


e External. Events occurring outside the 80286 processor’s environment are communicated to the 
processor via the INTR or NMI (non-maskable interrupt) pins. The NMI is interrupt 2. Other 
external interrupts share the INTR pin via one or more 8259A Programmable Interrupt Controllers, 

_ which can map each interrupt to a unique interrupt ID in the range 32-255. ) 


e Processor. When the processor detects a condition that it cannot handle, it communicates this fact 
by causing an interrupt with an ID in the range 0-16 (except for interrupt 2, which is the NMI). 


¢ Software. Programs can generate signal events by executing the instructions INT n and. INTO. 
With INT n, the value of n can be any interrupt indentifier in the range 0-255. This gives software 
the ability to simulate hardware interrupts as well as the ability to cause interrupts that are not © 
directly associated with hardware events. (Note that many software systems use the software inter- 
rupt to call on operating-system services. With the iAPX 286, an interlevel CALL through a CALL 
gate serves this purpose.) 
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When an interrupt occurs, the processor uses the interrupt identifier as an index into the interrupt 
descriptor table (IDT). | | 


Enabling and Disabling Interrupts 


The interrupt flag (IF) controls whether the processor immediately reacts to external events. | When 
reset, IF masks out signals presented to the INTR pin. It has no effect on NMI, on processor-detected 
exceptions, or on software signals (INT and INTO). 


To set IF, use the STI instruction (ENABLE statement in PL/M-286); to reset IF, use CLI (DISABLE). . 


Interrupt Descriptor Table 


The IDT associates each interrupt identifier with a descriptor for the instructions that process the 
associated event. The IDT is similar to the GDT and LDTs but is different in two important respects: 


» The processor retevences the IDT only as the result of an interrupt. 


. The only descriptors permitted in the IDT are three kinds of gate descapion task gates, interrupt 
gates, and trap gates (descriptor types 5-7, respectively). | 


The IDT may dwell at any location i memory. The processor locates the IDT via the IDT register. 
The operating system uses the instruction LIDT (load IDT) to set the IDT register. The instruction 
SIDT (store IDT) reads the contents of the IDT register. There can be only one IDT, but the operating 
system can use the LIDT instruction to substitute another array of gate descriptors. 


Interrupt Tasks and Interrupt Procedures 


In response to an event, the processor interrupts the currently executing task and begins executing the 
instructions identified by the IDT gate descriptor that is associated with the event. The instructions 
that execute as the result of the event may either be 


¢ A task other than the current ack 


¢ A procedure within the current task 


If the descriptor indexed by the interrupt identifier is a task gate, which points to a task state segment, 
then the processor causes a task switch. Figure 6-1 illustrates the links that identify the interrupt task. 
Chapter 4 discusses the mechanisms associated with task switching and considers the impact that 
hardware task switching has on the eperaune; system’ s task eee 


If the descriptor indexed bye the interrupt identifier is either an interrupt gate or a trap gate (which 
point to executable segments), then no task switch occurs. Instead the processor behaves similarly to 
the way it would if the current task had called the indicated procedure via a call gate. Figure 6-2 
illustrates the links that identify the interrupt procedure. The iAPX 286 protection mechanism requires 
either that the target segment have a privilege level numerically less than or equal to CPL or that the 
target segment be conforming. If one of these conditions is true, then the indicated procedure begins 
executing in the current task. The major mechanical difference between invoking a procedure by an 
interrupt and invoking by a CALL is that; with an interrupt, the processor pushes the flag word onto 
the stack of the invoked procedure before the return address (as illustrated in figure 6-3) and clears 
the single-step flag (TF). 
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Figure 6-1. Interrupt Vectoring for Tasks 
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Figure 6-2. Interrupt Vectoring for Procedures 


Note that if an interrupt occurs while a privilege-level 0 (PL-0) procedure is executing, an attempt to 
transfer to a less privileged level violates protection rules. (The same protection rules apply as for a — 
CALL to a less privileged segment.) In general it is impossible to predict when an interrupt occurs; 
therefore, it is equally impossible to avoid a protection violation when a less privileged procedure has 
an interrupt gate or trap gate in the IDT. — : 
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Figure 6-3. Interrupt Procedure’s Stack 


What is the difference between an interrupt via an interrupt gate and an interrupt via a trap gate? In 
the case of an interrupt gate, the processor automatically disables interrupts before transferring control 
to the interrupt procedure; therefore, an interrupt gate is normally used with external interrupts. In 
the case of a trap gate, the processor does not disable interrupts; therefore, trap gates are normally 
used with processor-detected exception conditions, which are also known as “traps.” 


The IRET instruction returns control from an interrupt regardless of whether a task gate, interrupt 
gate, or trap gate is used to enter the interrupt handler. In all cases, executing IRET restores IF to its 
value before the interrupt. In the case of an interrupt procedure, the processor restores flags from the 
stack; in the case of an interrupt task, from the interrupted task’s TSS. 


The difference in speed between handling an event by a task gate versus by an interrupt or trap gate 
is not great, as table 6-1 illustrates. | 


OPERATING SYSTEM RESPONSIBILITIES _ 


Given the number of hardware features that automate event handling, you might wonder what is left 
for the operating system to do. In fact, for static systems in which interrupt tasks do not call on operat- 
ing system functions and in which there is no need to change the IDT, the operating system need not 
concern itself with interrupts. Few applications are so simple, however. The following sections discuss 
some extensions to the processor’s event-handling features that you may find useful in your operating 
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Table 6-1. Interrupt Response Time 


- Response Time (in number of clock cycles) — 


Operation | Interrupt or 
Trap Gate 
(to different PL) 


Hardware interrupt a 
| processing _ 


Save registers 

_ PUSHA done by 
PUSH DS task switch 
PUSH ES 


Initialize registers 
MOV AX,SEG item-1 
MOV DS,AX 
MOV AX,SEG item-2 
MOV ES,AX - ~ 


Total Clocks 


system. The common goal in all these extensions is to structure the software so that, when an event 
occurs, the hardware can handle interrupt administration chores antomaucely within the efficiency 
and protection requirements of the application. | 


done by 
task switch 


Manage IDT 

Many applications require the ability to change the association between an event and the procedure or 
task associated with it. Even relatively static systems require this ability if interrupt procedures and 
interrupt tasks are not loaded until after system initialization. Only PL-O procedures can effect run- 


time changes to the IDT because the data-segment alias for the IDT should have PL 0. The techniques 
for changing the IDT are.similar to those already illustrated in Chapter 2 for the GDT and LDTs. 


Switch Scheduling | Modes 


An application may include tasks that run sometimes as interrupt tasks and other times as normal tasks 
under the supervision of the Spcreune system’s scheduler. Examples of such situations include the 
following: | | 


¢ An interrupt task calls on operating system services that might force the task to wait (for example, 
RECEIVE_MESSAGE). 


e The task loader (in a dynamic system) does not distinguish between interrupt tasks and regular 
tasks, leaving it up to the task itself to request that the operating system attach it to an interrupt. 
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If such situations can arise, the operating system must 


¢ Keep track of whether a task is in hardware-scheduled mode or in software-scheduled mode 


e Provide services to switch a task between hardware-scheduled and software-scheduled mode 


Note, however, that an interrupt task that is in software-scheduled mode cannot service interrupts. If 
it is. possible for further interrupts of the same type to occur during the time the interrupt task is 
-software-scheduled, then switching to software-scheduled mode is not such a good idea. An alternative 
strategy is to allocate interrupt-servicing duties among two or more tasks: one hardware-scheduled and 
the others software-scheduled. The hardware-scheduled task responds to the interrupt and invokes one 
of the software-scheduled tasks through a mechanism such as message-passing as discussed in 
Chapter 5. If there are any delays in servicing that interrupt, it is one of the software-scheduled tasks 
that waits, not the hardware-scheduled task. | | | 


Manage Interrupt Controller 


Intel’s 8259A Programmable Interrupt Controller (PIC) is key system resource in a multitasking system. 
The 8259A PIC is a flexible device that gives the main processor the ability to service up to 64 external 
events via the processor’s single INTR pin. The 8259A PIC gives software control over such critical 
parameters as the relative priorities among interrupts and the means for acknowledging interrupts. 
Correct operation of the system requires proper use of the interrupt controller. For the operating system 
to manage this critical resource is only consistent with the protection features of the iAPX 286. 


At system initialization the operating system may initialize the 8259A PIC according to system config- 
uration and the needs of the application. Initialization may include 


e Setting the 8259A to operate in iAPX86 mode 

e Setting up master/slave relationships when the hardware configuration includes multiple PICs 
e Specifying whether interrupts are triggered by edge or by level : 

° Setting interrupt priority mode: rotating or masked 

e Determining whether priority is fully nested (if priority is set by masking) 


° DelcHmining whether. tues are acknowledged automatically or by explicit EOI command 
Refer to the Coriiponent Data Catalog for details of these and other ee of the 8259A PIC. 


If you choose an interrupt policy in which the 8259A automatically determines interrupt priority and 
automatically acknowledges interrupts, then there may be no need, after initialization, for either the 
operating system or interrupt tasks and procedures to deal with the 8259A. If, on the other hand, you 
choose a dynamically changing priority scheme (whether by specific rotation or by mask commands) 
or explicit end-of-interrupt commands, then you must also choose whether run-time control of the 8259A 
is the responsibility of the interrupt tasks and procedures or of the operating system. 


For the operating system to maintain run-time control over the 8259A PIC, it may provide a procedure 
such as the following that applications programs CALL instead of executing the IRET instruction. 


WAIT_FOR_INTERRUPT PROC FAR 
IRET ; Switch to task on back-link 


gh . Execution resumes here upon interrupt 
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ne oe Send interrupt mask to PIC 
RET ; Return to application procedure ~ | 
WAIT_FOR_INTERRUPT ENDP 


The operating system executes the IRET instruction within WAIT_FOR_INTERRUPT. 
WAIT_FOR_INTERRUPT would need to run as a privileged procedure within the calling task. With 
this approach, the operating system has control just before the task begins to wait for an interrupt as 
well as when the task begins to execute after the interrupt occurs. The operating system then has the 
opportunity to send interrupt masks, end-of-interrupt commands, and specific priority rotation 
eee as appropriate for the application. | | 


Provide Task-Level Interrupt Procedures _ 


GDT interrupt procedures (i.e., those invoked via interrupt gates and trap gates in the IDT that point _ 
to executable-segment descriptors in the GDT) provide a global mechanism for a task to’ react to 
events. The mechanism is global in the sense that one set of interrupt procedures applies to all of the 
tasks in the system. For example, suppose a GDT interrupt procedure handles the “divide error’ excep- 
tion. Then, a divide error in task A is handled by the same procedure as a divide error in task B because 
there is just one gate for divide errors. There is often a need, however, for one task to take different 
action than that taken by other tasks. For example, task A may need to terminate in case of a divide 
error, while task B may need't to continue. 


INTERRUPT DISTRIBUTION 


The software system designer has a choice of mechanisms that make it possible for different tasks to 
have different interrupt procedures for a given interrupt type 


1. LDT-based interrupt procedures 
2. An interrupt distributor 


You must deploy alternative | carefully. If a trap or interrupt gate in the IDT contains a selector for. 
an LDT slot, then there must be a system-wide convention that every LDT will have an appropriate 
descriptor in that slot. When the interrupt occurs, the processor uses the LDT of the current task to 
locate the interrupt procedure. 


Alternative 2 demands less from convention, but more from the operating system and the processor. 
With this approach, each task has (in the task database) a table that is its own private analog of the 
IDT. The operating system supplies a GDT interrupt procedure that merely indexes the current task’s 
handler table to find a pointer to the appropriate handler procedure. If the task does not supply an 
interrupt procedure for a specific interrupt, the operating system can invoke a default procedure. 


CONFORMING INTERRUPT PROCEDURES 


For certain interrupt procedures (for example, a divide-error exception handler that substitutes a fixed 
value for the quotient), the appropriate privilege level at which to run the interrupt procedure is the 
same as that of the interrupted procedure. In these cases, the interrupt procedure can be placed in a 
conforming segment. lor intcrrupt procedures in conforming segments, the processor automatically 
sets CPL to the DPL of the segment containing the interrupted procedure. Note, however, that this 
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technique does not apply to procedures called by an interrupt distribution procedure (because the 
distribution procedure always runs at PL 0). 


“OUTWARD CALL” 


An Geapplcation’ may contain : some iiteenip procedures that should run at a fixed privilege level that is 
chad than zero. | 


The processor, on the other hand, prevents calls from PL nto PL m if n<m. For privilege-checking 
purposes the processor treats interrupts to procedures as calls. It is a privilege violation if the interrupt 
procedure resides in a segment that has a DPL numerically greater than that of the interrupted proce- 
dure. Since interrupts may occur at arbitrary times, it is possible for CPL to be less than the DPL of 
the interrupt procedure, which would be an exception. 


A similar problem results when an interrupt distribution procedure (which runs at PL 0) attempts to 
call a less privileged procedure identified in the task’s interrupt handler table. The problem results 
even if the interrupt distributor attempts to simulate a conforming interrupt procedure by using the 
interrupted procedure’s CPL as the RPL value in the selector of the interrupt handler. | 


The operating system can employ the shadow task strategy to overcome this contradiction. Figure 6-4 
outlines the shadow task strategy for invoking a lesser-privileged procedure from PL 0. Only a PL-O 


TASK’S 
HANDLER 
TABLE 


SHADOW TASK 
TASK’S 
HANDLER 
PROC 


OS INTERRUPT 

PROCEDURE __ 

(PL 0) 
pees MAIN TASK 


_. INTERRUPT 
iD 


‘ : 
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| Figure 6-4. Private Interrupt:Procedure | 
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procedure such as the interrupt distribution procedure described previously can implement this mecha- 
nism. Instead of calling the handler procedure (which could be a privilege violation), the operating 
system’s interrupt procedure 


e Creates a shadow task containing the handler procedure 
¢ Sets the CS and IP fields of the shadow task’s TSS to the entry point of the handler procedure 
e Calls the shadow task | 


An IRET instruction in the interrupt handler procedure returns control to the interrupt distributor 
procedure in the main task. 


Creating a shadow task involves simply allocating space for the new TSS and initializing it. Setting the. 
LDT field of the new TSS to the same value as in the main task’s TSS lets the shadow task have access 
to all the same segments as the main task, including the segment containing the handler procedure. 
The operating system may create the shadow task either at the time the main task is created or dynam- 
ically, at the time the interrupt occurs. 


Provide Software Signals 


In some applications there is a need for one task to send a signal to another task that is not waiting for 
the signal. The “quit” signal in an interactive system is an example. For the target task to respond 
quickly to the signal, the signal must trigger some form of interrupt mechanism. The mechanisms 
described previously for private interrupt procedures have the appropriate features: each task can define 
the action to take upon receipt of the signal, and the signal handler can run at a restricted privilege 
level. Additional components needed to implement software signals include 


e Extended task handler table with entries for each possible software signal 


e Operating system procedure that any task can call to send a signal to another task 


A software signalling mechanism is also a convenient way for the operating system to signal tasks. This 
method is particularly suited to 


e Reporting exception conditions detected by the operating system 


e Giving a task the chance to put its affairs in order before the operating system terminates it. 
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CHAPTER 7 
HANDLING EXCEPTION CONDITIONS 


When the processor recognizes a condition that it cannot handle, an exception condition, operating 
system or applications software must temporarily take control and dispose of the condition. Exception 
conditions are also known as “faults.” 7 7 


FAULT MECHANISM 


The processor reports an exception condition by causing one of a predefined set of interrupts; one 
interrupt vector is associated with each exception condition that the processor recognizes. As with any 
interrupt, either a procedure or a task can field a fault. Faults resemble other interrupts, but they 
differ in two significant ways: 


e You cannot disable a fault. 


° For certain faults, the processor pushes an error code onto the stack of the fault handler (whether 
procedure or task) to help with recovery. 


FAULT RECOVERY 
When a fault occurs, the fault handler has three possible ways of dealing with the exception: , 


e Ignore it and continue execution of the task. 
e Fix the problem and retry the faulting instruction. 
e Kill the faulting task. 


Ignoring an exception is not generally advisable. Killing a task is sometimes unavoidable, but, for 
critical tasks, the handler should make every effort to recover from the exception. In many cases, the 
iAPX 286 helps the exception handler identify the faulting instruction and the conditions that caused 
the fault. 


Locating the Faulting Instruction 


Usually, a fault handler can locate the faulting instruction either via the return pointer on the stack (if. 
the exception handler is an interrupt procedure) or via the IP stored in the TSS of the faulting task (if 
the exception handler is an interrupt task). This stored value of the IP is used to return control to the 
interrupted task, but the exception handler can also use the stored IP value to examine the faulting 
instruction. There are three cases to consider: 


e The stored IP value points to the location of the faulting instruction (including all prefixes). This is 
the normal case. 


e The stored IP value points to the location of the next instruction. 


e The stored IP valuc is unrelated to the fault. This occurs, for example, sith 80287 instructions 
(which execute in parallel with 80286 instructions), or when the 80286 processor discovers a fault 
while attempting to handle an external interrupt. 
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Error Code 


With exceptions that may relate to a specific segment, the processor pushes an error code onto the 
stack of the exception handler (whether procedure or task). Figure 7-1 illustrates the error code. The 
format of the error code resembles that of a selector. However, instead of an RPL field, the error code 
contains two one-bit items: 


¢ The processor sets the EX (external) bit when the fault does not directly result from an action of 
the task. Occurrence of this condition generally indicates a “system” problem as opposed to an 
“application software” problem. 


e The processor sets the I (IDT) bit if the index portion of the error code refers to a gate descriptor 
in the IDT. When the I bit is set, the handler can ignore the TI bit. If the I bit is reset, then the TI 
bit identifies either the GDT or an LDT, just as in a selector. 


The index field identifies the descriptor associated with the exception (if any). 


In some cases the error code on the stack is null, in which case all bits in the word are zero. For some 
faults, the handler can gain additional information about the fault by determining whether the error 
code is null. : | 


APPLICATION INTERFACE 


Since some of the actions appropriate for exception conditions depend on the requirements of individ- 
ual application. programs, the operating system may need to provide an application interface to the 
exception handling system. Chapter 6 discusses mechanisms for doing so. 


EXCEPTION CONDITIONS 


The action appropriate to each type of exception depends both on the type of exception and the needs 
of the application. This section provides details for each type of exception. Some of the exception 
conditions are identified by a two-character mnemonic that some other Intel literature uses. 


| = 11F DESCRIPTOR IS IN IDT 


EX = 1 IF EXCEPTION DETECTED DURING 
EVENT EXTERNAL TO TASK 
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Figure 7-1. Exception Error Code 
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Interrupt ae Error 


This exception may occur during DIV (unsigned divide) and IDIV Gnteper divide) instructions. The 
processor causes a divide-error exception in case of division by zero or quotient overflow. 


A divide-error handler might, for example, replace the quotient with a predetermined value and permit 
the faulting task to continue. The return pointer indicates the first byte of the divide instruction, so the 
handler must increment the return pointer before returning. 


Interrupt 1—Single Step 


The processor causes a single step exception at the end of every instruction when the TF (trap flag) is 
set. When the processor invokes any interrupt procedure, it saves the flags and resets the TF so that 
the exception handler does not cause a single-step exception. pxecuune IRET at the end of the excep- 
tion handler restores TF. 


The exception handler for this exception typically belongs to a debugging system. Single stepping is a 
valuable debugging tool. It allows the exception handler to act as a “window” into the system through 
which you can observe task operation instruction by instruction. A single-step handler may, for example, 
display register contents, the value of the instruction pointer, key variables, etc., as they change after 
each instruction. 


The single-step exception handler should take care, however, not to violate the system’s protection goals 
by its actions. To protect the operating system from the debugging activities of an applications 
programmer, the debugger should not give access to the more privileged levels. The debugger can 
check, either before or after each instruction, whether the instruction causes a control transfer to a 
prohibited level. After such a transfer, the return pointer identifies the next instruction in an accessible 
segment. The debugger can set a breakpoint at that instruction and suspend single stepping until the 
breakpoint trap occurs. , 


Interrupt 3—Breakpoint 


The INT 3 instruction causes this exception. The INT 3 instruction is one byte long, which makes it 
easy to insert a breakpoint anywhere in an executable segment. The operating system or a debugging 
subsystem can use a data-segment alias for an executable segment to place an INT 3 instruction anyplace 
where it is convenient to arrest normal execution so that some sort of special processing can be performed. 
Debuggers typically use breakpoints as a way of displaying registers, variables, etc., at crucial points 
in a task. 


The saved IP value points to the next instruction. If.a debugger has replaced a planted breakpoint with 
a valid opcode, it must subtract one from the saved IP value before returning. 


Interrupt 4—Overflow 


This exception occurs when the processor encounters an INTO instruction and the OF (overflow) flag 
is set. Since signed arithmetic and unsigned arithmetic both use the same arithmetic instructions, the 
processor can not tell which is intended and therefore does not cause an overflow exception. Instead it 
merely sets OF when the results, if interpreted as signed numbers, would be out of range. When doing 
arithmetic on signed operands, careful programmers and  SOMDIICIS either test OF directly or use the 
INTO instruction. . 
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An exception handler usually terminates the faulting task; however, in some applications it is feasible 
to place a “maximum value” in the receiving alae and pal the task to continue. The return 
pointer indicates the next instruction. 


Interrupt 5—Bound Check 


This exception occurs when the processor, while executing a BOUND instruction, finds that the operand 
exceeds the specified limits. This condition usually indicates a programming error. The safest action 
for the handler is to terminate the faulting task. In some applications, however, it is feasible to “adjust” 
the erroneous operand. The return pointer points to the beginning of the faulting instruction. 


Interrupt 6—Undefined Opcode (UD) 


This. exception occurs when the processor detects an invalid operation code in the instruction stream. 
Such an exception may occur, for example, if a programmer mistakenly causes a jump to read-only 
data in an executable segment. This exception has several variations: 


e The first byte of the instruction is completely invalid; for example, 64H. 


e¢ The first byte of the instruction indicates a two-byte opcode, but the second ye is invalid; for 
: example, OFH followed by OFFH. 


¢ One of the operands of. the instruction is not valid for use with the opcode. 


¢ The opcode extension in the second byte of an instruction contains a value that is invalid for use 
with the opcode; for example, opcode OF6H with xx001XxxB in the second byte. 


¢ The opcode requires a memory operand, but the operand actually indicates a register, for example, 
LGDT AX. 


The offending opcode is invalid, so the handler should not restart the instruction. 


You can use this exception to implement extensions of the iAPX 286 instruction set. The exception 

handler would interpret the instruction and advance the return pointer beyond the extended instruction 

before returning. 

Interrupt 7—Processor Extension Not Available (NM) 

This exception occurs in either of two conditions: 

e The processor encounters an ESC (escape) instruction, and the EM (emulate) oe of the machine 
status word (MSW) is set. | | : 

¢ The processor encounters a WAIT. paeials and both the MP (math present) and TS (task 


- switched) bits of the MSW are set. 


Refer to Chapter 12 for details concerning the 80287 Numerics Processor Extension. 
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Interrupt 8—Double Fault (DF) 


This exception occurs when tiie processor detects an exception while trying to invoke the handler for 2 a 
prior exception, for example: 


e The code segment containing the exception handler is marked “not present.” 


e Invoking the exception handler causes a stack to overflow. 


The processor pushes a null error code onto the stack. If this or any other action while invoking the 
double-fault handler causes an additional fault, the processor shuts down. To avoid the catastophe of a 
shut-down, the double-fault handler must be a separate task (so that pushing the error code does not 
cause a stack fault) and must away: be present (so that invoking it does not cause a “not present” 
fault). | 


Recovery is sometimes possible by eliminating the cause of the second exception and re-executing the 
faulting instruction so that the original fault can be handled appropriately. The greatest difficulty lies 
in identifying the cause of the second exception. Often, however, a double-fault condition indicates a 
serious error, and the faulting task should be terminated. 


Interrupt 9—Processor Extension Segment Overrun 


This exception occurs when a memory operand of an 80287 instruction has a segment-limit violation. 
Since the 80287 executes in parallel with the 80286, the occurrence of this exception may not relate 
directly to the instruction stream being executed by the current task. A task switch may have occurred 
since the 80287 began executing the instruction. Even if the interrupted task is the correct task, its IP 
may have been advanced by several instructions sesh the 80287 instruction. Refer to See 12 for 
more ¢ information about this exception. | 


Interrupt 10—Invalid TSS (TS) 
This exception occurs when the processor detects any of the following abnormalities in a TSS: 


1. The value of the limit field of the a a to the TSS is too small (discovered during a task 
switch). 


2. The LDT indicated in the TSS is invalid or not present (task switch). Note that a null LDT 
- selector does not cause an exception during a task switch. 


3. One of the segment register fields (SS, CS, DS, or ES) in the TSS is invalid (task switch). 
4. One of the privileged-stack selectors is invalid (interlevel CALL). 
5. The back-link selector is invalid (intertask IRET). 


This exception does not occur when a segment-register field or the back link is marked “not present” 

but is otherwise valid. A “not present” exception occurs in this case. If, during an interlevel CALL, 
a privileged-stack selector in the TSS points to a descriptor marked “not present,” then a stack 
exception occurs. | | 


The handler for this exception must be a separate task, invoked via a task gate in the IDT. The proces- 
sor pushes an error code onto the stack of the handler. The error code either identifies the faulty 
TSS (case 1) or contains the faulty selector from the TSS (cases 2-5). The instruction causing the 
fault can be restarted. An IRET at the end of the exception handler causes one faulting instruction to 
execute again. 
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A few of the conditions that can cause this exception are recoverable. If the system incorporates virtual 
memory, the solution for a not present LDT may be to bring it in from virtual store. In the case of an 
invalid back-link, you can make the assumption that the NT flag was set by mistake, give control to 
the scheduler, and hope.... | , 


Interrupt pe iMoacaess Not Present (NP) 


This exception occurs hen the. processor deieets that the present bit of a descriptor i is reset. It may 
occur in any. of these cases: | 


While loading the CS, DS, or ES vegisiers but not while indie the SS register (a stack fault , 
occurs in that case). 


. While loading the LDT register with an LLDT instruction, but not while loading the LDT register 
_ during ¢ a task switch operation (the “invalid TSS” fault occurs 1 in n that case). 


* While attempting to use a gate that is marked ‘ ‘not present.” : a 


An operating system typically uses the “not present” exception to implement a virtual memory system. 
Refer to Chapter 9 for more information on virtual memory. | | 


The processor pushes an error code onto the-stack of the exception | handler. The error code contains 
oe selector of the cecnyie that i is marked “not. present.” . 


‘A “not present” anaieations in a gate Geacriotoraisually has special significance for the operating system. 
For gates in the IDT, the present bit may serve as a sign that the interrupt task is in software scheduled 
mode and temporarily unable to service an interrupt. If an interrupt arrives in this case, there may be 
an error either in the device that generates the interrupt or in the handling of the Interrupt Mask 
Register of the 8259A PIC. (Refer to Chapter 6 for more information on interrupt handling). For gates 
in the GDT or LDTs, the present bit may serve to signal an unresolved linkage. (Refer to Chapter. 11 
for mornanon on ee i 


The instruction that « causes a “not prescnt fault is restartable (except in the case of a task switch). 
Execution of an IRET by the exception handler causes the processor to execute the faulting instruction 
again. When the processor detects the “not present” exception while loading CS, DS, or ES during a 
task switch, the exception ¢ occurs: in the - new task, and the return Pa points to the first instruction 
of the new task. 


Interrupt 12—Stack Exception (SS) 
This exception occurs in either of two general conditions: 


As a result of a limit. violation i in any operation that refers to the SS register. This includes stack- 

oriented instructions such as POP, PUSH, ENTER, and LEAVE as well as other memory refer- 

ences that implicitly use SS (for example, MOV AX,[BP+6] ). ENTER causes this exception when 

the stack is too small for the indicated local variable space. An interlevel CALL references two 
| stacks; a stack-limit exception can result from either of them. 


e When attempting to load the SS register with a descriptor that is marked “not preset but i is 
- otherwise valid. This can occur in a task switch, an interlevel CALL, an interlevel return, or a MOV 
or POP instruction to SS. 
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The processor pushes an error code.on the stack of the exception handler. If the exception is due to a 
not-present stack segment or to overflow of the new stack during an interlevel CALL, the error code: 
contains a selector to the segment in question (the exception handler can test the present bit in the 
descriptor to determine which exception has occurred); otherwise the error code is null. 


The instruction that causes a stack fault is usually restartable. Execution of an IRET by the exception 

handler causes the processor to execute the faulting instruction again. The one case that is not restart-. 
able is a PUSHA or POPA intruction that attempts to wrap around the 64K boundaries of a stack. 
segment. This condition is identified by one of the values FFFEH, FFFFH, 0000H, or 0001H in the . 
saved SP. 


When the processor detects a stack fault while loading SS during a task switch, the exception occurs 
in the new task, and the return pointer has the value that the IP field of the new TSS held at the time 
the task switch began. | | 


When stack overflow causes the exception, the stack fault handler can increase the size of the stack 
segment (up to a maximum of 64K) and permit the faulting task to continue. When the exception is 
due to a stack segment not being present, recovery action resembles that of the “not present” fault. 
handler. Oo 


“Interrupt 13—General Protection Exception (GP) 


All protection violations that do not cause another exception cause a general protection exception. This 
includes (but is not limited to) 

«. Exceeding segment limit when using DS, ES, or CS__ 

e Exceeding segment limit when ace a descriptor table 

¢ Jumping to a data segment ao | 

¢ Writing into a read-only segment or an executable segment | 

¢ Reading from an execute-only segment 


e Loading the SS register with a read-only descriptor (unless the selector comes: from the TSS during | 
a task switch, in which case a TSS exception occurs) : 


° Loading DS, ES, or SS with the descriptor of a system segment 

° Loading DS, ES, or SS with the descriptor of an executable segment . : 

| ¢ Loading CS (by means of a CALL, JMP, or interrupt) with the descriptor of a data segment 
e Accessing memory via DS or ES when it contains a null selector 

e« Switching to a busy task — 

e Violating privilege rules 


The processor pushes an error code onto the exception handler’s stack. If loading a descriptor caused . 
the exception, the error code contains a selector to the descriptor; otherwise the error code is null. | 


The return pointer points to the beginning of the faulting instruction. Recovery may be possible, but 
because programming errors cause most of the conditions leading to a general protection exception, | 
recovery may not be worth the trouble required to identify the cause. ~ | 


A string instruction (any variant of INS, OUTS, MOVS, STOS, SCAS, or CMPS) with a repeat prefix 
(REP, REPE, or REPNE) is not restartable if it causes a segment limit violation. Check whether SI 
or DI is near the segment limit. 
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An instruction that both tests and modifies the carry. uae is not restartable ODE: RCL, RCR, or 
Eee) 7 
Interrupt 16—Processor Extension Error (MF) 

The 80286 causes ihis exception when it detects a signal from the 80287 on the 80286's ERROR input 
pin. The 80286 tests this pin only at the beginning of certain floating- -point instructions and male it 


encounters a WAIT instruction while the EM bit of the MSW is reset (no emulation). 


Refer to Chapter 12 for more information on this exception. 


Interrupt 17—Run-Time Exceptions 
Intel’ s run-time support software uses this interrupt to communicate exception conditions regarding 


range checks and procedure stack overflow. Sepa one should avoid using this interrupt for any other 
purpose. 


RESTARTABILITY SUMMARY 


Table 7-1 summarizes the information pertinent to restarting the faulting instruction. 


Table 7-1. Restart Conditions 


Return Address 
Exception ~ Relative to 
“ee Faulting Instruction 


Restartable? 


Divide error : First byte | | ~ No 
Single step Next instr. 7 No | 
Breakpoint | Next instr. .. No | 
Overflow Next instr. : No- 
Bound check | First byte ; No 


Undefined opcode 


Processor extension | 


not available | 
Double fault 


Processor extension 
segment overrun 


Invalid TSS 

Segment not present 
Stack exception 
General protection 


-Processor extension 
error 


First byte 
Unrelated 


First byte 
Unrelated 


First byte 
First byte 


.. First byte 


First byte 
Unrelated 


No 
No — 


Yes 
(always null) 


No 


Yes 
Yes 
Yes 
Yes 
No 
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CHAPTER 8 
INPUT /OUTPUT 


Many of the concepts previously introduced in this book apply to the design of the I/O subsystem of 
an operating system; in addition, the iAPX 286 has several I/O features of special interest. 


The functions typically performed by an I/O subsystem include 


e Centrally implementing and standardizing I/O logic so that all application programs can share it. 


¢ Providing a uniform, high-level interface by which application procedures can request I/O services 
(as a minimum, the functions READ and WRITE). A more sophisticated system may need a full, 
file-oriented set of interfaces such as Intel’s Universal Development Interface (UDI). 


e Administering device naming. Often this includes transforming logical device identifiers into physi- 
cal identifiers, so that applications that use the logical identifiers can maintain independence from 
physical devices. 


e Managing use of memory resources for I/O buffers. 


e Managing sharing of physical devices. Often this reduces to giving one task exclusive use of a device 
(for example, a printer) until the task relinquishes it. With disk devices, tasks can usually share the 
device as long as each uses a different set of disk addresses. A sophisticated database-management 
system may require unlimited disk sharing (the database system assumes responsibility for block- 
level synchronization, deadlock detection, and recovery). 


e Providing device-driver procedures to deal with the vagaries of various I/O devices. 

° Optimizing I/O efficiency. This might include any of these techniques: blocking, buffer pooling 
automatic seek-ahead, reduction of disk arm movement. 

This discussion of I/O classifies physical I/O operations thus: 

e Direct I/O, in which the 80286 processor itself communicates directly with the peripheral device. 
Direct I/O breaks down further into 7 


a. Memory-mapped, in which I/O is triggered by processor instructions chat reference certain 
memory locations. 


b. I/O-mapped, in which special I/O instructions cause the processor to do I/O. 
e Indirect I/O, in which an external processor (such as the Intel 8089 I/O Processor) performs the 


1/O 
1/0 AND PROTECTION 


The concept of protection as applied to I/O deals not only with the memory used in I/O operations 
but also with the right to execute I/O operations. 


I/O Privilege Level (IOPL) 


You can limit to specific privilege levels the right to execute I/O and I/O-related instructions. IOPL 
(a two-bit field in the flag word) restricts a task’s right to execute any of these instructions: 


IN input 
INS input string 
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OUT output 

OUTS output string 

STI set interrupt flag (enable interrupts) 
CLI clear interrupt flag (disable interrupts) 


LOCK lock bus 


When interpreting any of these restricted instructions, the processor compares CPL to IOPL. If CPL 
exceeds IOPL, the processor causes a general protection exception and does not carry out the 
instruction. 


Only a privilege-level 0 (PL-0) procedure (i.e., the operating system) can change IOPL. There is no 
instruction that explicitly affects IOPL; however, any of the operations that load the flag word can, in 
some cases, change IOPL. The.only mechanisms for changing the flag word are 


© A task switch 
_ © The POPF (pop flags) instruction 
e IRET | 


When CPL is greater than zero, the POPF instruction does not change IOPL, even though it changes 
other flags in the flag word. The processor issues no error indication when this occurs. A task switch 
loads the flags from the Task State Segment (TSS). As long as the operating system does not make 
data-segment aliases for the TSS available to less privileged levels, only the operating system can 
change IOPL in the TSS. | 


For maximum protection, the procedures of an I/O subsystem that run in the calling task should run 
at a protection level numerically greater than the operating-system kernel but less than applications 
procedures. IOPL can then include the I/O subsystem but exclude applications procedures. Used this 
way, IOPL forces less privileged application procedures to call on I/O subsystem procedures for I/O 
functions, thereby giving the operating system control over many I/O operations. | 


Tasks that deal primarily with I/O (device drivers, for example) may have an IOPL value as great as 
three: If that is the case, all procedures in the task have access to I/O operations, yet all four privilege 
levels are available to protect the procedures of the task from one another. 


Controlling I/O Addresses 


Protection is incomplete if not applied to memory accesses by I/O operations. IOPL does not apply to 
memory-mapped I/O nor to interface with intelligent controllers (because none of the restricted 
instructions are used). The operating system designer must make special Provisions to control these 
I/O operations, either via the operating system or with the Builder. 


HARDWARE ADDRESS CHECKING 


Memory-mapped I/O is subject to the segment-level protection mechanism of the iAPX 286. A task 
can execute a memory-mapped I/O operation only if it has access to a descriptor for a data segment 
that contains one of the memory addresses reserved for I/O. Giving a task descriptors for only the 
I/O memory addresses that it has the right to use yields a double benefit: | 


e The task cannot access I/O devices assigned to other tasks. 


¢ Within the task, I/O is restricted to those procedures whose privilege level is numcrically less than 
or equal to the DPL of the I/O memory address segments. 
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You can still take advantage of I/O memory address protection even though the I/O devices on the 
bus respond to I/O commands. A hardware address mapper can convert the processor’s memory cycles 
for the I/O memory space into I/O cycles on the bus. The address mapper will not initiate a bus I/O 
cycle unless the memory operation passes the processor’s protection checking. 


SOFTWARE ADDRESS CHECKING AND CONVERSION | 


With indirect I/O, the external controller accesses I/O buffers independently of the 80286. This presents 
a three-fold ere to the operating system: | | 


° Memory access by the controller is not subject to the automatic protection checking of the 80286. 
e The controller (probably) uses “flat” addresses (i.e., addresses that are not relative to a base address). 


e The addressing range of the controller may not coincide completely with that of the 80286. 


The flow of eaiitrel for indirect I/O requests must pass through operating-system srbeeduies at PL 0 
SO that the operating system can 


e Check memory addresses and privilege levels against information stored in the task’s descriptors 


¢ Transform base-relative addresses to a flat format recognizable by the controller 


1/0 AND MEMORY MANAGEMENT 


An] /O subsystem can place additional requirements on the operating system’ § memory manager; or | 
example: | 


e I/O functions may use certain dedicated memory locations (for example, the addresses used for 
memory-mapped I/O, and the communication blocks and buffers that external controllers expect 
to find a fixed locations). The memory manager must be aware of these locations and must not 

allocate them for other purposes. 


¢ When buffers: for external controllers are allocated dynamically, addressing limitations of the 
controller. may require the memory manager to find space within the portion of memory that the 
controller can address. ) 


e Once it allocates a segment for the use of an external controller, the memory manager must not 
move, delete, or swap out the segment without cooperation from the controller. 


PARTITIONING I/O FUNCTIONS 
To determine how best to distribute I/O functions across tasks and privilege levels, you must consider 


¢ The opportunities for parallelism 
e The needs for synchronization 
e The requirements for protection 


8-3 | 121960-001 


Intel | INPUT/ OUTPUT 


Requirements for Parallelism and Synchronization: 


The cequirements for parallelism and synchronization i in the I / O subsystem may include | es of the 
following: | | | Ee 


e The application procedure that requests a READ operation may run in parallel with the I/O subsys- 
tem until that procedure needs to reference the requested data, at which point it must wait until 
the data arrives or an exception occurs. 


¢ The procedure that requests a WRITE operation can usually run in parallel with the I/O subsys- 
tem. Some applications require acknowlegement of the completion of a WRITE operation (in order, 
for example, to synchronize with a database recovery system), in Eyane® case that eects must 
- wait until the acknowledgement arrives. — 


¢ SEEK operations normally run in parallel with the requesting procedure. 


¢ The I/O device can always run in parallel with some task in a multitasking system, whether it be 
the task that requested the I / O operation or some other task that is not waiting for I/O. 


¢ Ina simple I/O subsystem in which a device driver only manages one I /O operation at a time, the 
driver can simply wait until the device signals that the operation finishes. If the requesting proce- 
dure is blocked, the device driver can merely convert the I/O- -complete signal into a wake-up signal 
for that procedure. 


¢ Ina more sophisticated I/O subsystem (for example, one in which a disk driver handles n more ‘than 
one spindle and more than one task can share a disk device), greatest efficiency results only when 
device drivers run in parallel with I/O devices as well as with requesting procedures. An I/O- 
complete signal from a device may arrive when the device driver is busy. 


Figure 8-1 explains the symbols used in a Petri net graph. Figures 8-2 and 8-3 use Petri net graphs to 
illustrate two approaches to synchronization between parts of an I/O subsystem. A horizontal line 
represents an event of interest that occurs only under certain conditions. Circles preceding an event 
represent the conditions under which the event can occur. Circles after an event’ represent the condi- 
tions that result from occurrence of the event. A dot inside a circle is called a token. A token represents 
a condition that is in effect. An event occurs if and only if there are tokens for all its input conditions. 
When an event occurs, , tokens flow into all its output conditions. — 


Figure 8-2 assumes the simple device driver mentioned re and points out how such a driver can 
service only one task at a time. Figure 8-3 shows how a two-part driver can deal with more than one 
I/O request at a time (assuming that the I/O device can do so as well). I/O requests from applications 
procedures drive part A, while interrupts drive part B. Not shown by the Petri net graphs is the fact 
that the two parts of the driver must share information about outstanding I/O requests. Both figures . 
show simplified device drivers to highlight the interactions among parts of the I/O subsystem; for 
example, a real device driver may issue multiple physical I/O commands in response to one I/O request 
and may retry I/O operations in case of certain error indications from the device. 


Requirements for Protection 


The requirements for protection in an I/O subsystem include (in addition to the protection considera- 
tions previously discussed) 


Device allocation tables and any other data used by the primary I/O interface procedures must be 
protected from all but those procedures privileged to do I/O, but must be available to every task in 
which the I/O interface procedures can run. 


e Only the device driver should have access to a device’s control Paramerets (for example, head settling 
time for a disk drive). 
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* Only the operating system and the I/O subsystem should use queues of buffers and I/O requests. 
¢ An application procedure must not use a buffer that an I/O device is simultaneously using. 


Implementation Alternatives 


If descriptors for data global to the I/O subsystem (such as device allocation tables) reside in the GDT 
with DPL equal to the I/O privilege level, then I/O procedures can access them regardless of what 
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Figure 8-1. Petri Net Graph Symbols 
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Figure 8-2. Synchronization with Simple Device Driver 
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Figure 8-3. Synchronization with Two-Part Device Driver 
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task the I/O procedures run in. The I/O interface procedures (READ, WRITE, etc.) must have DPL 
equal to that of the global I/O data and therefore must have call gates at the privilege level of appli- 
cation procedures (PL 3). If these call gates reside in the LDTs of application tasks, then I/O interface 
procedures can be shared by (but limited to) those tasks that need them. The call gates can also reside 
in the GDT, where all tasks can access them. In either case the interface procedures run in the calling 
task. 


The possibilities for running device drivers in parallel with the calling task suggests that they be separate 
tasks. Such a separation also serves to protect applications and device drivers from one another, a 
definite advantage because inherent complexity and frequency of change tend to place device drivers 
among the least reliable of operating system functions. The I/O interface procedures have the respon- 
sibility for managing the details of communication between the calling task and the device drivers. 


You can implement a sophisticated device driver such as that illustrated in figure 8-3 as two cooper- 
ating tasks: one scheduled by interrupts via a task gate in the IDT, and the other scheduled by I/O 
requests via an Operating-system mailbox facility. 


It is possible to implement device drivers as interrupt procedures that run within applications tasks. 
Such a structure is advantageous in these cases: 


e Efficiency of I/O is an overriding goal. 


e Interrupts may arrive when a driver is busy. 


The lack of protection inherent in such a structure becomes apparent, however, when you consider that 
the driver procedure that fields an I/O-complete interrupt may run as part of a task completely unrelated 
to the task that originally requested the I/O operation, and must run at PL 0. 


Viewing the possible implementations of buffers from the perspective of the iAPX 286 architecture, 
the most pertinent consideration is whether a segment contains just one buffer or several buffers. An 
approach that uses one segment per buffer has several advantages: 


e The protection mechanism of the iAPX 286 (working as it does on segment descriptors) focuses on 
each buffer individually. 


e The selector of a buffer segment serves as a convenient buffer identifier, fitting easily into the 
aliasing and mailbox schemes outlined in Chapter 5. 


You can avoid the potential GDT congestion that may result from having one segment (and therefore 
at least one segment descriptor) per buffer by storing buffer descriptors in LDTs. 


When tasks share buffers (as between an application task and one or more device-driver tasks), you 
have a choice between 


e Leaving the buffer at all times within the address spaces of all the sharing tasks 
¢ Transferring the buffer from the address space of one task into that of another 


The mailbox scheme outlined in Chapter 5 easily accomplishes the latter approach. This scheme has 
the advantage that the application task cannot use the buffer at the same time as I/O is in progress. 
The “usage privilege level” (UPL), if set to IOPL, provides additional protection by limiting mailbox 
access to I/O procedures. The application’s requirements for I/O efficiency may, however, preclude 
use of mailboxes for this purpose. 
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CHAPTER 9 
VIRTUAL MEMORY 


The memory legitimately addressed by the tasks running on an iAPX 286 (the virtual memory) may 
exceed the actual memory available. You can use this capability to lower memory costs, substituting 
disk or other less expensive storage media for relatively expensive RAM. Virtual memory isolates 
programmers from the amount of real memory in a computer system. The system designer can trade 
off performance against system cost using identical software. : 


A system that supports virtual memory can be analyzed in terms of mechanisms and policies. The 
iAPX 286 has mechanisms that help your operating system manage the swapping of segments between 
RAM and less expensive memories. The operating system must implement additional mechanisms as 
well as policies for efficient use of these mechanisms in a specific application. 


HARDWARE MECHANISMS 


The 80286 provides the essential hardware mechanisms without which virtual memory systems would 
not be possible. The segment is the basic unit of the virtual-memory scheme, just as it is the basic 
unit of the real-memory scheme. In each segment descriptor, the iAPX 286 architecture provides an 
accessed bit and a present bit to 0 aid the operating system in simulating the virtual memory space with 
available RAM. : | 


Accessed Bit 


Every descriptor for an executable segment or data segment has an accessed flag in the least signifi- 
cant bit position of the access rights byte. Each time a task loads segment register with a segment 
descriptor, the processor automatically sets the accessed bit in that descriptor. The processor does not 
automatically reset the accessed bit; software must explicitly write a zero into the accessed bit. The 
accessed bit has a dual function in virtual memory manacemeny 


e By testing and then resetting the accessed bit at regular intervals, the virtual-memory manager can 
measure how frequently the segment is being accessed. | 


¢ For writable data segments, the accessed bit (when set) indicates that the segment may have been 
changed. 


Present Bit 


Every segment descriptor has a present flag in the high-order bit position of the access-rights byte. The 
processor automatically tests this bit as it loads segment registers. If the present bit is reset, the proces- 
sor causes a trap. Which trap depends on the circumstances: 


¢ Trap 11 (Segment not Present) occurs when loading the CS, DS, or ES register with a not-present 
segment descriptor, when switching to a not-present TSS, when loading the Task Register by means 
of the LTR instruction with a not-present TSS descriptor, or when loading the LDT register with a 
not-present LDT descriptor. 


e Trap 11 also occurs when loading CS with a gate descriptor that is marked “not present.” This 
condition does not necessarily mean that a segment is not present, however. The operating system 
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may attach other meaning to the present bit of gate descriptors. Refer to the section on load-time 
binding in Chapter 11 for an example of an alternate use for the present bit in gate descriptors. 


¢ Trap 12 (Stack Exception) occurs when loading the SS register with a not-present descriptor. The 
exception handler can distinguish this condition from other stack exceptions by examining the access 
rights byte of the descriptor selected by the error code. 


¢ Trap 10 (Invalid TSS) occurs when switching to a TSS that points to a not-present LDT. The 
_ exception handler can distinguish this from other “invalid TSS” conditions by examining the access 
rights byte of the descriptor selected by the error code. 


¢ Trap 8 (Double Fault) occurs if the processor, while trying to invoke an exception handler due to a 
previous exception, finds that the code segment containing its entry point is not present. The diffi- 
culty of distinguishing between this and other double fault conditions implies that wep 8 is to be 
treated as an error condition, not a normal use of the present bit. 


Refer | to Chapise 7 foe additional information about these traps. 


SOFTWARE MECHANISMS 


The operating system must provide additional mechanisms for a virtual memory system: one for moving 
a segment from RAM to secondary storage (the swap-out manager) and one for moving a segment 
from secondary storage to RAM (the swap-in manager). 


The swapping managers are essentially I/O modules, but there are major differences between swapping 
managers and the functions of a standard I/O subsystem: 


° ‘Swappers deal with executable segments, system segments, and data segments that are not normally 
considered I/O buffers. 


. | /O performance of swappers is critical and often calls for specialized device drivers and disk space 
allocation Stategies. 


Secondary Storage Management 


Virtual-memory mechanisms use a secondary storage medium, such as disk, to simulate a larger memory 
space than that provided in RAM. The operating system uses this secondary storage (here called the 
swap space) to store copies of those segments that are currently in the virtual space but may be 
eliminated from RAM. 


There are two general approaches for allocating swap space for segments in dynamic systems: 


¢ The loader can invoke a swap- space allocation procedure as it loads the segments of a task. It can 

-at the same time write an initial image of the segment into the swap space. This is particularly 

useful for a segment such as an executable segment that is occasionally swapped in but may never 

be swapped out (when its RAM space is used. for another segment) due to the fact that its contents 
do not change. 


¢ The operating system may invoke the swap-space allocation procedure dynamically, either when 
allocating RAM for the segment or at the first time the operating system swaps the segment out. 


Some operating systems may implement both approaches. A system that allocates swap space only at 


load-time cannot swap out certain segments; namely, segments that a bootloader creates initially and 
segments that the operating system creates dynamically. In many systems, this 1s not a problem. Often 


9-2 121960-001 


intel VIRTUAL MEMORY 


those segments that are bootloaded are just the segments that should not be swapped out. Other operat- 
ing systems may allocate many segments dynamically: stacks, mailboxes, variable-length arrays, etc. 
These systems may need both approaches. 


In designing a dynamic swap-space allocation scheme, you should consider at what time it is best to 
allocate swap space. The procedure that first allocates RAM space for a segment (a loader, for example) 
often creates a writable data segment descriptor. Later, when the procedure has initialized the segment 
(for example, by writing descriptors into a segment that is to be used as an LDT), it modifies the type 
code in the descriptor to reflect the intended use of the segment (in this example, it would change the 
type to LDT). By delaying the allocation of swap space until first swap out, the operating system never 
allocates swap space for segments that it never swaps out (there is no need to allocate swap space for 
an LDT, for example, if the operating system does not support swapping of LDTs). 


Once the operating system allocates swap space for a segment, it must store the swap-space address in 
_a location that is easily accessible when it 1s time to swap the segment out. Two possible mechanisms 
for storing the swap-space address are 


e Ina boundary tag of the segment, if boundary tags are used. (Refer to Chapter 3 for an example 
of a space-management scheme that uses boundary tags.) 


e Ina table parallel to the descriptor table. 


To determine whether to call the swap-space allocation procedure when it is time to swap a segment 
out, the operating system can test whether the swap-space address field contains a null value. 


When a segment is not present, the operating system can use the 24-bit base-address field in the segment 
descriptor to store the address of the swap space in which the segment is stored. As long as the present 
bit of a descriptor is reset, the processor does not use the base-address field. Storing the swap-space 
address in the descriptor also makes the swap-space address readily accessible to the “not-present” trap 
handler because the error code presented to the trap handler contains a selector to the descriptor for 
the not- prevent segment. 


Level Zero Support Procedures 


While the swapping procedures are I/O procedures that should run at privilege levels greater than 
zero, protection of the system demands that highly privileged procedures carry out some details of the 
swapping process. Only privilege-level 0 (PL-0) procedures have the right to perform such activities as 


e Create read-data or write-data alias descriptors with which the swappers can access the segments 
they are operating on 


e Change the present bit in a descriptor 
e Overwrite the base-address field of a descriptor | 
¢ Prevent the swapper from operating on segments that must remain RAM-resident 


¢ Update all the alias descriptors for a segment with its new status 


The following checklist identifies some of those segments that should remain permanently in RAM (in 
your ADEA en there may be others): 


© The. GDT. (It is the key to all addres ppets ions: ) 


¢ LDTs that refer to present segments. (The processor cannot access an LDT segment without fetch- 
ing its descriptor from the LDT.) 
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e TSSs that point to present LDTs. (You cannot switch to a task and use its LDT without referring 
- to its TSS.) 


e TSSs whose NT (nested task) flag is set. 


e Certain operating-system kernel segments that are frequently referenced (for example, the segment 
or segments containing the scheduler’s queues). (System performance may degrade excessively.) 


° Segments belonging to the swapping managers. — 
¢ I/O buffers that are in use by an external device. 


¢ Executable segments that contain ae entry point of an exception handler. (An exception would 
result in a double fault.) 


Note that, while the iAPX 286 does offer mechanisms that support swapping of TSSs and LDTs, doing 
so is likely to cause not-present faults in PL-0 procedures and to cause unacceptable delays in invoking 
interrupt tasks that are not present. For either of these reasons, the designers of an operating yetem 
may elect not to swap out TSSs and LDTs. 


Swapping Managers 
Swapping managers may need to distinguish between two classes of segments: 


e Segments of a task superstructure (the TSS, the task database (TDB), and possibly the level-zero 
stack segment) 


° ‘Segments not part of a task superstructure 


Swapping of the task superstructure requires that swapping managers be aware that the kernel may 
treat the TSS as a “subsegment” of the TDB, which may itself reside within the level-zero stack (as 
outlined i in Chapter 4). The swapping managers should treat these segments as a unit. 


Considering the complexities associated with swapping the segments of the task superstructure, it is 
perfectly reasonable for an operating system to simplify its virtual-memory subsystem by leaving those 
segments in RAM for the duration of the task. 


OUT-SWAPPER 


The out-swapper works best as a separate task; when the out-swapper must wait for the swapping- 
‘device I/O driver to write a segment, other tasks can continue to run, including the task whose segment 
is being swapped out. 7 


The out-swapper’s responsibility is to 


e Mark all the descriptors for the segment “not present.” The out-swapper must ensure that the present 
bits in all descriptors for a segment always appear consistent. It must use a semaphore or region to 
prevent other access to the aliases while it is changing present bits. 


e Copy the swap-space address into all the descriptors for the segment (or possibly, depending on 
alias implementation, into a “master descriptor” that is linked to other descriptors). 


e Create a temporary data-segment descriptor to give the swapper the right to read the segment. The 
operating system must not move or delete this segment until the out-swapper is finished with it. 


e Write the segment to the swap-space allocated for it (but only if the segment is writable and its 
accessed bit is set). 
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e Return the RAM space used by the segment. 


¢ Delete the temporary data-segment descriptor. 


IN-SWAPPER 


In theory, the fetch policy module, invokes the in-swapper. In practice, when the fetch policy is ‘‘on 
demand,” the in-swapper is the “not-present” fault handler, which may also be called by the stack 
segment fault handler (for not present stack segments) and by the “invalid TSS” fault handler (for not 
present LDTs). The not-present fault handler can run as a procedure in the task that caused the fault. 


There is one case, however, that such a procedure cannot handle well. A dispatcher procedure running 
in task A causes a not-present fault when switching to task B whose TSS is not present. If the not- 
present handler procedure continues running in task A, then task A must wait until task B’s TSS can 
be swapped in. Whether this is a problem depends on the role of task A in the application. The not- 
present handler procedure can avoid this situation by suspending task B and sending a message to yet 
another task that is dedicated to swapping in TSSs. 


The steps that an in-swapper procedure takes are to 


¢ Get the swap-space address and segment size (limit) from the descriptor indicated by the error code. 
e Allocate a writable data segment in RAM large enough to receive the segment. 
e Copy the segment from swap space to the newly allocated RAM space. 


¢ Update all regular descriptors for the segment with the new base address, setting the present bit 
and resetting the accessed bit. (The base address comes from the temporary writable data-segment 
descriptor.) 


e Delete the temporary writable data-segment descriptor. 


An in-swapper task for not present TSSs gets a message from its input mailbox that identifies the 
descriptor for the TSS and identifies the task to which the TSS belongs. The in-swapper task performs 
the same steps as an in-swapper procedure, but it must also inform the scheduler when the task is 
ready to run. You can avoid the additional complexities of not-present TSSs by not swapping TSSs 
out. 


COORDINATION OF IN- AND OUT-SWAPPER 


A number of interactions between the i peswebper and out-swapper present pitfalls that the operating 
system must avoid: 


e A task may attempt to use a segment that is being swapped out. If the in-swapper does not handle 
this possibility, it may swap in old, erroneous data from the swap-space. 


e Task A may request swapping in of a shared segment that is being swapped in for task B. If the in- 
swapper blithely reads in the segment again for task A, it may overwrite changes made by task B. 


e A task may delete a segment that is being swapped out. If the swap-space release procedure does 
not allow for this case, the segment’s swap space may be released and reallocated while. the out- 
swapper is writing to it. 


The in-swapper, out-swapper, and swap-space release procedures can control these interactions by 
maintaining a shared table of all segments that are in transition. They must use a semaphore or region 
to coordinate access to the shared table. The swap-space address can serve as the segment identifier in 
the table. 
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SOFTWARE POLICIES 


A virtual memory system gives each task the opportunity to affect other tasks in the system. Tasks 
compete with one another for real memory resources. One task may attempt to use memory in such a 
way as to unduly impede the progress of other tasks. The operating system must enforce policies which 
ensure that every task makes appropriate progress. 


Virtual memory management policies are not unique to the iAPX 286; the computer-science literature 
contains many discussions of policies that apply to various classes of applications. There is, however, a 
distinction between segmented architectures and paged architectures. The iAPX 286 has a segmented 
architecture. Literature that deals with paged architectures may not apply to the iAPX 286. Refer to 
the paper by Denning (see “External Literature” in the Preface) for a broad survey of the science of 
virtual-memory management. a : 


The remainder of this chapter i is an introduction to nie mOnvananasenient policy. The policies you need 
to consider are of three types: fetch policy, placement policy, and replacement policy. 


Fetch 


The fetch policy determines which segment to bring from swap space into RAM and determines when 
to bring it in. . 


_The simplest fetch policy is to bring in a segment on demand, that is, at the time it is referenced. 
Under this policy, the operating system brings in a segment from swap space only when the processor 
causes a not-present exception as the result of a reference to the segment. 


All other fetch policies are in some way anticipatory. A simple example of an anticipatory fetch policy 
on the iAPX 286 is to always bring in the LDT of a task when bringing in its TSS. Some time-sharing 
systems implement an anticipatory policy that brings in all the segments of a task at once. This policy 
may be suitable for tasks that consist only of one code segment, one or two data segments, and stack 
segment (as, for example, simple BASIC programs submitted by students in a university environment). 
The swapping managers can use the escent register fields i in the TSS (CS, DS, ES, SS) to identify 
the task’s working set. 


Attempting to implement such a full-task swap policy for more complex tasks that use many ecenients 
may result in frequently fetching segments that are not referenced in any one time slice. 


The additional complexity of implementing an anticipatory fetch policy is justifiable only if the antic- 
ipatory policy performs better than the demand policy. Given the efficiency of the iAPX 286 exception 
mechanism and given that in a multitasking environment there is usually some other task to service 
while one task waits for the in-swapper to fetch a segment, an anticipatory policy typically does not 
provide significantly greater throughput. An anticipatory policy may give better performance, however, 
when judged by performance standards other than throughput (for example, interrupt latency for apecific 
tasks). 


Placement | 


Determining where in RAM to place an incoming segment is the subject of Chapter 3. In a virtual- 
memory system, however, the constant reallocation of real memory to segments of varying length places 
special demands on the operating system’s. memory management module. When choosing a space- 
management algorithm for a system that includes virtual memory, you may wish to give extra consid- 
eration to the trade-off between speed and memory fragmentation. : 
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Replacement 


The operating system may need to replace one or more other segments that already reside in real 
memory to make space for a segment that is the object of a “segment-not-present” fault. The replace- 
ment policy determines which segments to eliminate and when to eliminate them. | | 


The choice of which segments to evict from RAM is crucial to the performance of the system. The 
goal is to evict only segments that will not soon be referenced. The difficulty is knowing which segments 
will not soon be referenced. Many different policies are discussed in the literature. They fall into three 
general classes: | | . | 


e Naive policies that determine which segment to evict without any knowledge of segment access 
patterns | 


¢ Historical policies that use information about prior access patterns to determine the probability 
that a segment will soon be referenced 


e Optimal policies that use analyses of actual program control flow to determine the probability that 
a segment will soon be referenced 


HISTORICAL POLICIES 


The iAPX 286 architecture supports gathering of historical information about actual segment access 
patterns via the accessed bit in executable and data segment descriptors. An operating-system module 
that periodically tests and resets the accessed bits of descriptors can develop a “profile” of segment 
usage. The information gathered this way can be used both by the replacement policy module for run- 
time decision making and by the operating system designers for improving replacement policy. 


A “profiler” works best if it takes samples at regular intervals. To find all descriptors, it must step thru 
LDTs. A profiler does not need to examine all descriptors in the system each time it is invoked; it needs 
only to examine those of tasks that have run since the last time it was invoked. The same timer inter- 
rupt procedure used by the scheduler can invoke the profiler at appropriate times. 


A profiler may run either as a separate task or as a shared procedure in the current task. A profiler 
that runs as a procedure in the current task can easily locate the LDT with an SLDT instruction. The 
LSL (load segment limit) instruction helps the profiler find the size of an LDT. The LAR (load access 
rights) instruction enables the profiler to test the accessed bit. A profiler that runs as a separate task 
may require the support of a PL-0 procedure that locates LDTs and tests accessed bits in other tasks. 


A profiler must give special consideration to aliases. If the accessed bit in any of the aliases of a 
segment is set, the segment has been accessed. Here again, a PL-0 segment may be needed to step 
through the kernel’s alias lists. 


OPTIMAL POLICIES 


Many of the optimal policies discussed in the literature are of theoretical interest only. They are used 
as a Standard against which to measure the performance of more practical policies. 


The segment-register fields of the TSS provide support for a trivial, but possibly useful, optimal policy. 
The replacement policy can assume that, next time any given task runs, all the segments identified by 
the CS, DS, SS, and ES fields of the TSS will be referenced. The processor loads all these registers 
during a task switch and causes a fault at that time for each not-present segment. Since the task cannot 
run if any one of these segments is not present, the replacement policy may as well replace all of them 
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at once. It then becomes possible to allocate swap space for these segments in such a way as to minimize 
seek time. Such a policy works well with the full-task fetch policy outlined previously. 


THRASHING 
If not carefully controlled, the I/O traffic in support of virtual memory may degrade system perform: 
‘ance beyond acceptable limits. The worst case of performance degradation is called thrashing. This 


happens when RAM is committed to simulating an excessively large virtual-memory space and the 
behavior of the tasks in that space is such that no task can run without causing a not-present fault. 


You can avoid thrashing by measuring or estimating the minimum amount of RAM a task needs in 
which to operate without causing frequent not-present faults. If the task loader knows this figure, it 
can refuse to load a task when not enough RAM is available. You can measure a task’s RAM require- 
ments with a profiler such as that described previously. 
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CHAPTER 10. 
SYSTEM INITIALIZATION 


The initialization performed at power-on or RESET by the 80286 processor is not, by itself, adequate 
for running in protected mode. Software must perform additional initialization before it is possible to 
fully use protected mode. 3 bust 


INITIAL STATE 
When you Powe! up an 80286 system or prone a RESET, the state of the processor is as follows: 


° “The MSW (machine status word) is is zero; 1.e., the 80286 starts running in the edi adidieee mode: 
¢ CS:IP be set to FO00:FFFO, and the CS limit is OFFFFH. | 


¢ The four high-order address lines A3.99 are automatically asserted for all subsequent references to 
CS until your initialization code changes CS. 


e SS, DS, ES are set to zero, and the corresponding limit registers are set to OFFFFH. 
e The flag word is zero. This means that the 80286 starts running with the maskable interrupts disabled. 


The initial state of the address lines and CS:IP causes the processor to begin executing instructions at 
physical address OFFFFFOH. Presumably, this addresses a JMP instruction in an initialization proce- 
dure located in ROM or in RAM that has been loaded by another processor. The initialization proce- 
dure may occupy any portion of the last 65,536 bytes of the 16-megabyte address space. The JMP 
instruction at physical address OFFFFFOH transfers control to the actual beginning of the initialization 
procedure. The first instruction that modifies the CS register causes the processor to cease asserting 
the high-order four address lines; therefore, the initialization procedure must avoid using any instruc- 
tions that modify the CS register, except for the final JMP instruction. = 


The initial state of the DS, ES, and SS registers gives the initialization procedure access to the first 
65,536 bytes of the address space. The initialization procedure may change these registers, however, 
to gain access to any location in the first megabyte of the address space. (With regard to segmentation 
and addressing, the 80286 in real-address mode behaves just as an 8086. ) Access to other portions of 
mienery is E Possible only after switching into protected mode. , | 


SWITCHING TO PROTECTED MODE 


You use the LMSW (load machine status word) instruction to set the PE bit in the MSW, thereby 
switching the 80286 into protected, virtual-address mode. The current privilege level (CPL) starts at 
zero. The segment registers continue to point to athe same physical memioty areas as in real- pais 
mode. | : : 


Immediately after setting the PE flag, the initialization code must: flush the processor’s instruction 
queues by executing a JMP instruction. The 80286 fetches and decodes instructions and addresses 
before they are used; however, after a change into protected, virtual-address mode, the prefetched 
instruction information (which pertains to real-address mode) is no longer valid. A JMP forces the 
processor to discard the invalid information. An intrasegment JMP will cause the processor to drop the 
four high-order address lines; however, in protected mode this is not a problem. All addressing in 
protected mode uses the 24-bit base address from the segment descriptor; so, once in protected mode, 
all of physical memory is accessible. 
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INITIALIZING FOR PROTECTED MODE 


You can do most of the initialization needed for protected mode either before or after switching into 
protected mode. If done after, however, you must be careful to order the code so that it does not use 
protected mode features that require initialization that is not yet completed. 


Interrupt Vector 


The initial state of the 80286 leaves interrupts disabled; however, to ensure a predictable action in case 
an exception or non-maskable interrupt (NMI) occurs, it is a good idea to initialize the IDT register. 
Since it is unlikely that the NMI interrupt handler or any exception handler has been initialized, the 
most appropriate value to load into the IDT register is zeros, thereby guaranteeing a shutdown should 
an interrupt happen. (The 80286 signals shutdown externally as an indication of a severe problem.) 
Later, when interrupt service routines are ready, you can change the IDT register to point to an actual 
IDT that contains gate descriptors for the interrupt routines. Interrupts may be enabled at that time. 


Stack 


Before you perform any stack operations, whether in real-address mode or in protected, virtual-address 
mode, you must load the SS register with a descriptor to a stack segment in RAM. If the SS register 
is loaded in real-address mode, it continues to point to the same segment after the switch into protected, 
virtual-address mode. | 


Global Descriptor Table 


Before you change any segment euler in eee | virtual-address mode, the aoe register must 
point to a valid GDT. abs 35 


The GDT (as well as me)? should reside in RAM because the pieces! modifies the accessed bit of 
descriptors. 


To allow full 16-megabyte addiessine in the initialization code, you may find it convenient to build a 
temporary GDT that contains only enough descriptors to permit the initialization procedure to read 
the GDT segment from ROM or from a bootloadable module. After placing the real GDT into RAM, 
you can change the GDT register. 


STARTING FIRST TASK 


The initialization procedure can run awhile in protected mode without initializing the task register 
however, before the first task switch, two conditions must prevail: 


° There must be a valid task state segment (TSS) for the new task. The register fields of the TSS 
should have appropriate values, the segment register fields must point to valid segments or be null, 
the stack pointers for privilege levels numerically less than or equal to the initial CPL must point 
to valid stack segments, the LDT pointer must. point to the GDT entry for a valid LDT (or be null 
if the task does not use an LDT) and, just as insurance, the back link of the TSS should be null. | 


e The task register must point to an area in which to save the current task state. After the first task 
~ switch, the information dumped in this area is not needed, and the area can be used for other 
7 PURPOSES 
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Starting the first task is simply a matter of executing a long JMP via the descriptor of a TSS or via a 
task gate to that descriptor. This task can perform any remaining initialization work while enjoying the 
full protection and virtual-address features of the iAPX 286, the state assumed by the aap 
tools. 


EXAMPLE OF INITIALIZATION 


The following figures present a detailed example of one way to initialize a protected, virtual-address 
mode system. This example includes assembly anguage modules that work in conjunction with Builder 
speciconons | | 


Figure 10-1 shows the primary initialization module ENTP (ENTer E Protected mode). This module Bit 
the 80286 into protected, virtual-address mode and invokes the first task constructed by BLD286. You 
use a module such as ENTP by binding it with other modules (presumably those constituting the 
operating systen and the initial task) that you intend to place in EPROM. 


The module SEGS shown in figure 10-2 supplies damity segment descriptions for ENTP. The program 
INIT shown in figure 10-3 serves as the initial task. It merely aspiays a message when initialization is 
complete. : 


Initialization Module ENTP 
The steps that ENTP takes are to | | 


* Switch into protected mode 

e Create a temporary GDT 

¢ Create an IDT and GDT copy in RAM from tables 1 in EPROM | 

* -Point the CPU to the RAM tables. | 

¢ Copy all the TSSs and LDTs identified in the GDT fieen EPROM to RAM — 
¢ Update the RAM GDT to point to the RAM copies : | 
¢ JMP to the initialization task in the GDT 


The iditializations amediatels following RESET_STARTUP are redundant. They simulate thé 
hardware RESET initializations in case of a software reset or in case of a branch to 
RESET_STARTUP during debugging. 


INITIAL_ GDT is a temporary GDT containing een for t the IDT and the main GDT in EPROM 
(the one constructed by BLD286). Since the symbols for these descriptors, GDT_DESC and 
IDT_DESC, are PUBLIC, the Builder can insert the actual base and limit values into the table. 


The code in segment ENTP_CODE is self-relocatable. In an EPROM-based system, you would specify 
to the Builder the actual address of the segment ENTP_CODE, making sure that the entry point 
resides at physical address FFFFFOH. i 


ENTP assumes a specific format for the GDT constructed by BLD286. The first two ee are 
the data-segment aliases for the GDT and the IDT. The remaining descriptors are grouped according 
to the template defined by TASK_ENTRY. Three adjacent descriptors identify the key segments of 
each task. ENTP adapts at run time to the actual number of such groups in the GDT. The task that 
ENTP initiates is identified by a fixed position inthe GDT.  . | ; | | 
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SOURCE 


$TITLE 
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q 
m 
oOo 
+ 


ero 
em 
EN 
on 
=4 


BASE_L 


BASE_H 
“ACCESS 


GAPX286 MACRO ASSEMBLER Enter Protected Mode 960-516 : 3 date PAGE 


System-ID iAPX286 MACRO ASSEMBLER VX.Y ASSEMBLY CF MODULE ENTP 
OBJECT MUDULE PLACED IN 
ASSEMBLER INVOKED 3Y: 


C’Enter Protected Mode 960-5146") 


NAME ENTP 
PUBLIC IDT_DESC,yGDT_DESCySTART 


Switch the 80285 from real address mode into protected mode. 
The initial EPROM GOT, IDTs TSSs and LOT Cif any) constructed by 81D236 
are copied from EPROM into RAM. The RAM areas are defined by data 
segments allocated as fixed entri2s in the GODT. The CPU registers for 
the GOT, IDT, TSS, and LDT are set to point at the RAM based 
segments. The base fields in the RAM GDT are also updated to 
point at the RAM based segments. . 


Interrupts are disabled during this mod2 switching code. 
The EPROM basad GOT, ICTs, TSS, and LOT are checked to assure 
they are valid before copying them to RAM. If. any of the RAM-based 
alias segments are smaller than the EPROM segments they are to holds 
halt or shutdown occurs. In general any exception or NMI causes 
shutdown to occur until the first task is invoked. 


If the RAM segment is larger than the EPROM segment, the RAM segment 
is expanded with zeroes. If the initial TSS specifies an LDT, 
the LOT is also copied into LOT_ALIAS with zero fill if needed. 
The EPROM or RAM based GOT, IDOT, TSS» and LOT segments may be located 
anywhere in physical memory. Z 


Define layout of a descriptor. 
 §TrRuc : 
Dw 0 s Offset of last byte in segment 
Ow ; OW 0 : Low 16 bits of 14-bit address. 
IGH 08 Oo . 3: High 8 bits of 24-bit address 
DS 0 3 Access rights byte ” 
DW 0 ; Reserved word 
ENDS 


Define the fixed GDT selector values for the descriptors that 
define the EPROM based tables. 


Figure 10-1. Initialization Module ENTP 
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0001 


0082 
0092 


0081 
0060 
0001 
0004 
o02c 
002A 
0007 


01€0 ES69FE 


0000 


0000 
0000 0000 


Enter Protected Mode 960-516 © 


LINE. 


+1 


SOURCE 


a 


: | 
GDOT_ALIAS 
IDT_ALIAS 


START_TSS_ALIAS 


START_TASK 


EQU 
EQU 
EQU 
EQU 


START_LDT_ALIAS EQU 


ee of 2o UY oe ce wo 
m 


EQU 


1*STZE 
2*SIZeé 
3*SIZE 
4xSIZE 
S*SIZE 


1 


DESC 
DESC 
DESC 
DESC 


DESC... 


ee 26 66 66 26 SS 68 C8 8 C8 


Oo G0 eo 0b oo 


Define machine status word hit 


s 
2 


date PAGE 


GOTC1) is data segment space for GDT 
GDTC2) is data segment space for IDT 
GDTC3) is data segment space for TSS 
GOT¥C4) is TSS for starting task 


GDTC5) is data segment space for LDT 
“positions. 
Protection enable. 


Define particular values of descriptor access rights byte. 


Access byte value for an LDT 

Access byte value for data segment: 
expand ups level 0, writeable 

Access byte value for an idle TSS 
Privilege level field of access rights 
Define accessed hit 

Position of TI bit 


‘Size of a TSS 


Position of LOT in TSS 
TI and RPL field mask 


address to the mode switch code. 


- The. segment containing this code must be at physical address FFFEIOH 
to place the JMP instruction at physical addrass “FFFFOH. The base 
according to the size of this segment. 


DT_ACCESS EQU 82H 
OS_ACCESS EQU 92H 
TSS_ACCESS EQU 81H 
DPL EQU 60H 
ACCESSED EQU 1 
TI —EQU 4 
TSS_SIZE EQU 44 
LOT_OFFSET EQU (42 
TIRPL_MASK EQU ize DESC-1 
SEJECT 
: Pass control from the power up 
; address is chosen 
ENTP_CODE SEGMENT ER 
CS_OFFSET EQU OFE10H 
ORG 
JMP RESET_STARTUP 


26 2s @6 20 6 C8 


INITIAL_GOT 
NULL_DESC 


GOT and stack. 


ORG 


LABEL 
DESC 


ow 16 bits of starting address 


.] L 
, 
OFFFOH-CS_CFFSET; Start at address FFFFFOH 
> DO 
° 


0 


WORD 
<> 


o not change CS! 


Define the template for a temporary GOT used to locate the initial 
This data is copied to location 0. 

This space is also used for a temporary stack and finally serves 

as the TSS written into when entering the initial TSS. 


s Place remaining code below power_up 
4 address 


; Filler ard null I07 descriptor 


Figure 10-1. Initialization Module-ENTP (Cont’d.) - . 
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~ YAPX286 MACRD ASSEMBLER ~~ Enter Protected Mod2 369-516 ~~ OS DENY ee et NEE ate 
LOC OBJ LINE ‘SOURCE 
0002 0000 
0004 00 
0005 00 
0006 0000 : . ee ee | Po $e os | a 2 ) 
0008 0000 BE GOT_DESC... BESE crs 5 _.. .$ Besecriptor for EPROM SOT. 
QOO0A 0000 : — 
000C 00. 
000D 00 
OOOE 0000 7 ; | | ie : - Meee 
0010 0000 37 TOT_DESC ‘DESC <> $ Cescriptor for EPROM IDT 
0012 0000 we By ane 
0014 00 
0015 00 
0016 0000 .. Battie’ See sete “wees oo 
0018 0000 88 TEMP_DESC . DESC . <>” -. .. § Temporary descriptor 
001A 0000 . ou 3 sf | . ee 
001C 00 
001D 00 . 
001E 0000 | - 
- 89 <a : a Sa ou pekan Poe Seo 
90 + Define a descriptor which points the SCT at location 0. 
31 - This descriptor is also loaded into SS to define the initial 
92 3  , protected-mode stack segment. | 
93 a : , :. 
0020 3F00 94 TEMP_STACK CESC CENC_GDOT-INITIAL_GDT—-15090,0S_ACCESS,0> 
0022 0000 . | oes | a 
0024 00 
0025 92 
0026 0000 
95 #1 S$EYJECT 
96 ; 
97 ; Define the TSS descriptor used to allow the task switch to the 
98 : first task to overwrite this region of memory. The TSS overlsys 
- 99 s the initial GOT and stack at location: 0. 
100 ; . 
0028 3FO00 101 SAVE_TSS -- | . DESC <END_GOT~-INITIAL_GDT—-1y 0505 TSS_ACCESS,0>. 
002A 0000 Z i ; Ca Bie st Las ee g 
o002Cc 00 
0020 81 
002E: 0000 
102 > 
103 : Define the initial stack space and filler for the end of the TSS. 
104 aoe 
0030 (8 105 DW 8 DUP C9) 


- Figure 10-1. Initialization Module ENTP (Cont’d.). 
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0060 
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2800 
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33FF 
8EOF 
8ECT 
8ED7 
BC4000 


E80000 


50 
83ED5C 


2E0F015E00 
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Enter Protected Mode 960-516 date PAGE 
LINE SOURCE 

106 END_GDT LABEL WORD 

107 

108 START_POINTER. LABEL DWORD 

109 OW OsSTART_TASK ; Pointer to initial task 

110 H 

111 H Define template for the task definition list. 

112 H ; 

113 TASK _ENTRY STRUC + Define layout of task description 
114 TSS_SEL Ow ? s; Selector for TSS 

115 TSS ALIAS DW ? s Data segment alias for TSS 

116 LOT_ALTIAS DW ? s Data segment alias for LOT if any 
117 TASK_ENTRY ENDS 

118 

119 TASK_LIST TASK_ENTRY <START_TASK gSTART_TSS_ALIAS,START_LDT_ALIASD 
120 OW 0 s Terminate list 

121 

122 RESET_STARTUPS 

123 CLI 3 No interrupts allowed! 

124 CLD s Use autoincrement mode 

125 XOR DI,DI $ Point ES:DI at physical address 000000H 
126 MOV OS,DI 

127 MOV ES,DI 

128 MOV $S$,0T > Set stack at end of reserved area 

129 MOV ‘SPeEND_GDOT-~INITIAL_GOT 

130 #1 S$EJECT 

131 ; . 

132 , Forn an .adjustment factor from the real CS base of FFO0OD0CH to the 
133 : segment base address assumed by ASM286.. Any data referance mada 

134 ° into CS must add an indexing term (8P]-to compensate for the difference 
135 ; between the offset generated by ASM286 and the offset required from 
136 > the base of FFOQQOOK. 

137 ° oe —— 

138 START PROC s The value of IP at run time is not 
139 ; H the same as used by ASM285! 

140 CALL STARTI s Get true offset of STARTI 

141 START12 

142 POP 8P 

143 SU8 BP,IFESET START : Subtract ASM2286 offset of START1 
144 : leaving adjustment factor in SP 
145 LIOT NULL UDESCCTBP) s S2t up null TOT to force shutdown 
146 3 on any protection error or interrupt 
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LOC 


0055 
0068 
0068 
006C 


006E 
0071 
0074 
0077 


0079 
OO7E 
0081 
00383 
0085 
0088 
0088 


OO8E 
0092 


0095 


0097 
OO9A 
0090 
O0A0 
0043 
O0A6 
COA 
OOAC 


 ¢APX286 MACRO ASSEMBLER | 


OBJ 


807600 
892000 


OFO1E0 
000100 
OFO1FO 
EB00 


2E0F015620 


882000 
8EDO 
33C0 
oFO0DO 


B82800 
OFO00D8 


2£884608 


3D2F00 
723C 


BB0800 
BE0800 
E80600 
BE1000 
BB1000 
E8CD00 
B80800 
8ED8 


Enter Protected 


+1 


SOURCE 


ee es 06 


LEA 
vas MIV- 
REP MIVS 


‘: @@ @0 oe 


SUSY 
OR 
LMSW 
JMP 


LGOT 
MOV 


MOV... 
“XOR 


LLOT 


MOV 
af - LTR 
JECT - 


m 


ee ce ot ee oe 


“mov 
CMP 


J8 


Figure 10-1. 


Suiten to protected mode 


‘Mode 960-515 


STs INITIAL_ GDTC3P) 


CXsCEND_GOT-INITIAL_ gDT)/2 


ESsWORD PTR COII,CS?CS1I 


& 
+ 
N 
00 20 00 we 08 we ee 


TEMP_STACKC API 


AX, TEMP_STACK-INITIAL.{ GOT 


SS 4X 
AX, AX 
AX 


AX,sSAVE_TSS-INITIAL_GOT 
AX. 


os 20 @6 68 8 


AXsGCT_DESCCBOJ.LIMIT 
AX, 6*SIZE DESC-1 


ee 20 68 we 


BAD _GDT 


BX»GDT_DESC-INITIAL _GDT 
SIySOT_ALIAS 
COPY_EPROM_DT 

SI, IDT_ALIAS 

BX, IOT_DESC-INITIAL_GDT 
COPY_EPROM_DT 
AX,SOT_DESC-INITIAL_GOT 3; 
DS,AX 


date ~ — PAGE 


Copy the EPROM-based temporary SOT into RAM. 


: Setup pointer to SGOT 
s Set length Ripe 
+s Put into reserved RAM 


‘and set-up a stack, SOT, and LOT. 


-Get current MSW 


Sat PE bit 

Enter protected mode! 

Clear queve of instructions decoded 
while in Real Address Mode 


CPL is now 0» CS still points at 


FFFE10 in physical memory 


Put initial GOT into RAM area 
Setup SS with valid protected mode 
selector to the RAM GOT and stack 
at the current LOT to null 
ny references to it causes 
an exception causing shutdown 
Set initial TSS into the low RAM 
The task switch needs a valid TSS. 


Copy the EPROM based GDT into the RAM data segment alias. 
First the descriptor for the RAM data eranent must oe copied into 
the temporary GOT. 


Get size of GOT 


-Be sure'the last entry expected by 


this code is inside the GOT 


Jump if GDT isn’t big enough 


Form selector to EPROM GDT 
Get selector of GOT alias 
Copy into EPROM 

Get selector of IDT alias 
Indicate EPROM ICT 


Set up addressing into EPROM SOT 
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toc oBs) LINE SOURCE 


OOAE 880800 191 MOV BXsGOT_ALIAS $ Get GOT alias data segment selector 
0081 OF0117 192 LGOT C8x] >; Set GOT to RAM GOT 
193 pias +: SS and TR remain in low RAM 
194 ; | 
195 H Copy all task’s TSS and LOT segments into RAM 
tke ok <o 196 M i nr 
0084 8D5E44 . 197 LEA EX, TASK_LISTCBPI  - -  § Define list of tasks to set up 
0087 198 COPY_TASK_LOOP: pe Tyee - 
0087 E81800 199 CALL COPY_TASKS > Copy them into RAM 
OQOOBA 83C306 200 ADO “BX sgSIZE TASK ENTRY >» Go to next entry 
00B8D 2E€8807 201 MOV  AXsCSSCBXI.TSS_SEL ; See if there is another entry 
00CcCO OBCO 202 OR AX AX 
00C2 75F3 203 JNZ COPY_TASK_L9OO0P 
poe 204 4 
205 : With TSS, GOT, and LOT set, start up the initial task! 
— 206 H 
00C4 880800 207 MOV BXsGDT_ALIAS > Point OS at GODT 
QOCc7? BEDB 208 MOV. DS» BX - a 
00C9 68B1000 209 M3V = BX» IDT_ALTAS : Get IO0T alias data segment selector 
OOCC OFO1IF | 210 LIOT C8Xx] os ae > Set IDT for errors and interrupts 
OOCF ZEFF6E40 211 JMP START_POINTERCSP) s Start the first task! 
S eats ples 212 . 3 The low RAM area is overwritten with 
ai ~< 213 ; the current CPU context 
0003 -  ~—.. 214 BAD_GDT: - 
0003 F4 215 HLT > Halt here if GDT isn°t big enough 
ane aad . - 
217 START ENDP 
218 #1 $EJECT. 
219 : _ 
220 : Copy the TSS and LOT for the task pointed at by CS2BX. 
221 H If the task has an LOT it will be copied downy too. 
222 . BX and 8P are transparent. 
223 ; : 
0004 224 BAD_TSS: 
0004 F4 225 HLT , s Halt here if TSS is invalid 
0005 226 COPY_TASKS PROC. | et | me 
a . 227 a Lea | og 34 S21. 5 eee 
0005 B8E0800 228 MOV SI,GDT_ALIAS + Get addressability to GODT 
0008 S8EDE 229. MOV DS,SI Sey, — 
OODA 2E887T702 230 MOV STyCS2C8XI.TSS_ALIAS s Get selector for TSS alias 
OODE 8EC6 231 MOV. ES,SI a 3 Point ES at alias data segment 
OOEO OF03C6 232 LSL AXsSI 3 Get length of TSS alias 
OOE3 268837 233 MOV STeCSSC8&x3.TSS_SEL ; Get TSS selector 
OOE6 OFO2ZD6 234 ~. LAR DX,SI ; Get alias access rights 
OOES9 T5E9 235 JNZ BAO_TSS ; Jump if invalid reference 
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O0FS 
o0F8 
OOFB 


OOFD 
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0106 
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0100 
0110 
0114 
0115 
0116 
0117 
0119 
O11A 


01186 
O11F 
0123 
0127 


0129 
012A 
0120 


012F 
0131 


OBJ 


B8AD6 
S0E69F 
SOFES1 | 
T5D0F 


OFO3CE 
83F 928 
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C6440592 
BEDE 
E89800 


B80800 
8ED8 
8ECO 
2E883F 
2E8877T02 


Z2EBESFO02 
8B8362A00 
S1LE6FSFF 
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OFO2D6 
T53C . 


8AD6 
80E69F 
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LINE 


237. 


238 
239 
240 
241 
242 
243 


+1 


SOURCE 
MOV DL» DH 
AND DH,NOT DPL 
CMP DH, TSS_ACCESS 
JNZ BAD_TSS 
LSL CxX,SI 
CMP CX,TSS_SIZE-1 
J8 BAD_TSS 


DS points: at GODT. 


ee 66 ee ve 


MOV CSIJ.ACCESS,DS_ACCESS 
MOV DSoSTI- . 
CALL COPY_WITH_FILL 


MOV AX,GOT_ALIAS 

MOV DSsAX 

MOV ES sAX 

MOV OIF,CS:C8xI.TSS_SEL 
MOV ST¥,CS°CBXI.TSS_ALIAS 
MOVSW 

MOVSW 

LOOSW 

MOV AHyDL 

STOSW 

MOVSW 


EJECT 


See if a valid LOT is specified 
If so then: copy the EPROM varsion 


ee e@ @8 66 


ee ef 080 


e 
: 
e 
® 
e 
® 
e 
e 


@e 66 @©8 28 26 Ce 20 et 


date . PAGE 


Save TSS descriptor accass byte 
Ignore privilege 

See if TSS 

Jump if not 


Get length of EPROM based TSS 
Verify it is of proper size 
Jump if it is not big enough 


Setup for moving the EPROM based TSS to RAM. 


Make TSS into data segment 

Point DS at EPROM TSS 

Copy 9S segment to —S with zero fill 
CX has copy counts AX-CX fill count 


Set the GOT TSS limit and base address to the RAM values. 


Restore GOT addressing 


Get TSS selector 

Get RAM alias selector 

Copy limit 

Copy low 16 bits of address 

Get high 3 bits of address 

Mark as TSS descriptor 

Fill in high address and access bytes 
Copy reserved word 


for the startup task. 
into the RAM alias. 


MOV CSyCS:CBXI.TSS_ALIAS : 
MOV STyDSIWORD PTR LOT_OFFSET 
AND SIyNOT TIRPL_MASK : 
Jz NO_LDT ; 
PUSH SI : 
LAR OX,SI ; 
JNZ BAD_LOT : 
MOV DL,OH ; 
AND CHyNOT DPL : 


Address TSS to get LOT 


Ignor2 TI and RPL 
Skip this if no LOT used 


Save LDT selector 
Test descriptor 
Jump if invalid selector 


Save LOT descriptor access byte 
Ignore privilege 
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0148 
014C 
O14E 
0151 
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0157 


0158" 
015C 


015F 
0161 


0163, 


0164 


0165 . 


0166 
0168 
0169 


~ O16A 


O16A 
0168 
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016C 
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0160 


OBJ 


BOFE82 
7532 


26C 6440592 
BEDE 


.OF03C6 
€82600 


8BC8 


2E887704 
8EC6 
OFO3C6 | 
£81800 
EB4A00 | 


26887706 


50 
2407 


Enter Protected Mode 960-516 | 


LINE 


+1 


date 


Be sure it is an LDT descriptor 
Jump if invalid 


Mark LDT as data segment 


Point OS at EPROM LOT . 
Gat LOT limit 

Verify it is valid 
Save for later 


if goods copy to RAM. 


Get LDT alias salector 

Point ES at alias segment 

Get length of alias segment 
Verify it is valid 

Copy LDT into RAM alias segment 


LOT Limit and base address to the RAM copy of the LOT. 


Restore LDT alias selector 
Restore LOT selector 
Restore GIT addressing 


Move the 2AM LOT limit 

Move the low 16 bits across 

Get the high 8 bits 

Mark as LDT descriptor 

Set high address and access rights 


Copy reserved word 


All done 


Halt here if LOT is invalid 


Test the descriptor table size in AX to ey that zt is an 


Save length 


SOURCE 
CMP DH,DT_ACCESS ; 
JNE BAD_LOT : 
MOV EStCSIJ-ACCESSsDS_ACCESSS 
MOV DSsSI ; 
LSL AXsSI : 
CALL TEST_OT_LIMIT ; 
MOV CX, AX ? 
; Examine the LOT alias segment and, 
MOV SIT,CS:CBXIJ.~LDT_ALIAS ° 
MOV ESeSI. ° 
LSU AX,STI ° 
CALL TEST_DT_LIMIT ry 
CALL COPY_ WITH ~FILl . 
H Set the 
MOV SIeCS3LBXIJeLDT_ALIAS ° 
pap Dr ; 
MOV AXsGOT_ALIAS ; 
MOV ~ DS,AX _ 
MOV ES,AX 
MOVSW j ; 
MOVSW 4 
‘LOOSW | : 
MOV ArH, OL ; 
STOSW P4 
MOVSW ’ 
NO_LCOT: 
RET “4 
BAD_LOT: 
HLT : 
COPY_TASKS | ENDP 
S$EJECT 
M4 
PY 
H even number of descriptors in length... 
TEST_DT_LIMIT PROC 
PUSH AX ? 
AND : 
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0176 
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017F 
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0188 


018A 


0180 
0190 
0192 
0195 
0196 


0197 


O19A 
0198 
019C 


0190. 
019E 
019F- 
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OBJ 
3C07 
58 
7501 
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F4 
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8C00 

8ECO 
2606470592 
26C747060000 
OF03C3 
8BC8 
ES8DFFF 
BFO800 
8EDF 
BF1800 

57 

AD 

E8D2FF 


‘Enter Protected Mode 


LINE 


328 
329 


330 


331 


- aoe 


333 
334 
335 
336 
337 


338 
“339 
340 
341 


342 
343 
344 
345 


+1 


SOURCE | 
CMP 
- POP... 
_ INE 
RST 


BAD _OT_LIMIT: 


HLT 


TEST_ OT_LIMIT 


CD ee ee oe ce oo 


OPY_EPROM_ODT 


CaOPY_EPROM_OT 
SEJECT 


data segment at selector SI. 
cause shutdown! 


960-516 


ALy7 
AX 
BAD_DT_LIMIT. 


ENDP 


PRCC 


AXsSS 
ES,AX 
ESS CBXJ-ACCESS,DOS_ACCESS 
ES?SfBXI. RES» 0 

AX» BX 

CX eAX 

TEST_OT_LIMIT 
DI,GOT_DESC-INITIAL_GDT. 
DS,D0I . 

ODIs TEMP_ DESC-INITIAL_ GOT 
OF 


TEST_ DT_LIMIT 


oe 
DS 3X 


ENCOP 


ee ee 


ee 


ee Gt 60 88 86 oF 


ae 8 @8 66 G28 G8 686 


‘date | ‘PAGE 


Must be all ones 
Restore length 


All OK 


Die! 


Copy the EPROM DT at selector BX in the temporary GOT to tha alias 
Any improper descriptors or limits 


“Point ES:DI at temporary descriptor 


Mark descriptor as a data segment 
Clear reserved word - 

Get limit of EPROM DT 

Save for later 

Verify it is a proper limit 
Address &PROM GOT in OS 


Get selector for temporary descriptor 


Save offset for later use as selector 


Get alias segment size 


“Verify it is an even multiple of 


descriptors in length 


Put length into temporary 


Copy remaining entries into temporary 


ES now points at the GOT alias area 


DS now points at EPROM OT as data 
Copy segment to alias with zero fill 


CX is copy count, AX-CX is fill count 
Fall into COPY _WITH_FILL 


Copy the segment at DS to the segment at &S for length CX. 
Fill the end with AX-CX zeroes. 
allow odd byte operations. 


Use word operations for speed but 
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Loc) 6OBJ 


kee WARNING #160, LINE #403, SEGMENT CON 


ASSEMBLY COMPLETE, 


Enter Protected Mode 360-516 


LINE 


493 


404 


_ 1 WARNING, 


SOURCE 


COPY_WITH_FILL 


REP MOVSW 


STCSB 
“DEC 
EVEN_COPY: 
SHR 
REP  STOSW 


JNC 

STOSB 
EXIT_COPY?: 

RET 
COPY_WITH_FILL 


ENTP_COCE 


NO ERRORS 


TAINS PRIVI 


PROC 


SI,S!I 
OL,0! 
AX CX 
CX,l 
CXel 


AX,CX 
EVEN_COPY 


CXsCX 
EXIT_COPY 


EX 


CXel 


EXIT_COPY 


ENOP 


ENDS 
LEGED INSTRUCTIONS 
END 


e6 20 @8 @8 


es 


eo a¢ 


date 


Start at beginning of segments 
Form fill count 

Convert limit to count . 

Allow full 64K move 

Copy DT into alias area 


Get fill count and zero AX 
Jump if even byte count on cdpy 


Copy odd byte 
Exit if no fill 


Even out the segment offset 
Adjust remaining fill count 


Form word count on fill 


Clear unused words at end 
Exit if no odd byte ramains 


Clear last odd byte . 


Figure 10-1.- Initialization Module ENTP (Cont’d.) 
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LAPX286 MACRI ASSEMBLER DEFIN= SEGMENTS NIEQED FOR INIT Cove date - PAGE 


System-ID iAPX286 MACRO ASSEMBLER VX.-Y ASSEMBLY SF MCOULE SEGMENT_OSF 
JBJECT MODULE. PLACED IN 2FIsSEGS.035. 
ASSEMBLER INVOKED 3Y: 3©1:2ASM285.86 3°1:2S2G6S.486 


Loc OBJ LENE © SoURCE 
| 1 +1 S$TITLEC°DEFINE SEGMENTS NEEDED FCR INIT CODE”) 
; , one : 
3 NAME . SEGMENT_DEF 
4 te 
rime . 5 INIT_STACKO. SEGMENT RW 3 Define stack so mode.switch code can 
0000 2772? 5 sil DW ? ¢ run in protected node 
a a a ea INIT_STACKO ENDS 2 
8 
Sa ae 9 LOT_SEG - SEGMENT RW 3 Define alias segments. whose true 
0000 ¢8 - 10 Cw 8 LUP €?) : size must be set by the 8L0285 
2222 3 
2 . : | oe 
ma es fs 4 11 LOT_SEG ENCS ; command file 
12 
peer, ts 13 TSS_SEG SEGMENT. RW 
0000 ¢8 14 . OW. 8 CUP ¢€?) 
et eek oe os 
) , 
---- 15 TSS_SEG .. ENDS 
oe 16 - 
<= 17 IOT_SEG SEGMENT RW 
0000 ¢8 18 ees Dw 8 DUP (€?) 
2202 . 
——) kh | 
sa nae 19 TOT_SEG © ENDS 
7 20 . 7 
See 21 GOT_SEG SEGMENT RW 
0000 «3 22 Dw 8 DUP C€?) 
ce a 2 
) 
Soe 23 GOT_SEG ENCS 
24 
25 END 


ASSEMBLY COMPLETE, ND WARNINGS, NC ERRORS 


Figure 10-2. Dummy Segments for ENTP 
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LAPX286 MACRO ASSEMBLER INITIAL TASK 


System-ID iAPX286 MACRO ASSEMBLER VX.Y ASSEMBLY OF MODULE INIT_MOD 
OBJECT MODULE PLACED IN :FLSINIT.O8J 
ASSEMBLER INVOKED BY: 2F12ASM286.86 ZFI1ZINITeAB6 


LOC OBS LINE 
1 
2 
3 
4 
5 
once 6 
7 
=s== 8 
0000 27727 9 
“a 10 
11 
= Ss 12 
13 
14 
0000 496€697469616C 15 
69TA61T4S696F6E 
20436F60706C65 
746521 
0018 OD 
0019 OA 
001A 00 
16 
0018 17 
0016 8E0000 18 
OO1E FC 19 
O01F 20 
OO1F 2EAC 21 
0021 OACO 22 
0023 7408 23 
24 
0025 50 25 
0026 9A0000---- E 26 
0028 EBF2 27 
002D 28 
0020 F4 29 
30 
-—-- 31 


*** WARNING #160, LINE #31,- 


ASSEMBLY COMPLETE, ‘1 WARNING, 


SOURCE 


STITLEC°INITIAL TASK”) 


NAME INIT_MDD 

EXTRN COSFAR 
INIT_STACK STACKSES 10 
INIT_DATA SEGMENT RW PUBLIC 
DATA1 DW ? 
INIT_DATA ENDS 
INIT_CODE SEGMENT ER 


ASSUME DS:SINIT_DATA 


MESSAGE DB “Initialization Complete!” ,0DH,0AH,0 


INIT_STARTS 
MOV SI,OFFSET MESSAGE 
CLD 
MESS_LOOP: 
LODS CS:BYTE PTR CSI) 


OR AL sy AL 
Jz INIT_EXgT 
PUSH AX 
CALL co 
JMP MESS_LoopP 
INIT_EXIT: 
HLT 
INIT_CCOE ENDS 


SEGMENT CONTAINS PRIVILEGED INSTRUCTIONS 


32 


END INIT START, OSS INIT_DATAsSSZINIT_STACK 


NO ERRORS 


Figure 10-3. Initial Task INIT 
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CHAPTER 11 
BINDING AND LOADING 


Binding is the process of converting symbolic references into an implementation that the processor can 
utilize. The binding process spreads across many stages of software development, including source 
code, translators, binding utilities, loaders, and execution itself. Intel’s program development tools.include 
features that perform much of the needed binding. In some static systems no additional binding may 
be needed. In dynamic systems, however, you may choose to incorporate some binding functions in the 
operating system and related software in order to create a style of binding appropriate for the dynamic 
nature of your application. 


BINDING MODEL 


To ensure that the binding process works correctly, it is a good idea to start with a model of the system 
structure you wish to achieve. A binding model includes these factors: ae 


e Modules—dividing peoeeanniins into compilation units 
° Segmentation—distributing instructions and data of modules among physical Scemems. 7 . 
° . Interfaces—specifying the connections among modules i oa 


e Naming—choosing names for modules, segments, oC EMCTEACES: avoiding ambiguity but promoting 
flexibility © 7 | 


° Timing—determining when to bind various types of symbolic references 


As an example of a binding model, assume that the example modules presented in prior chapters 
constitute a complete operating system, called XOS, and apply each of these factors to XOS. 


Modules 
The criteria used to separate functions into modules may include 


e Comprehensibility. Each module collects together functions that support: a ‘single operating system 
concept of limited scope (for example, aliases, synchronization). 


¢ Information hiding. Each module implements a data structure (for example, the alias lists i in ‘tlie 
ALIAS module) that you can manipulate only by calling the procedures defined in the module for 
that purpose. Other modules cannot access the data structure. 


¢ Independent development. You can choose modules so that each can be developed by a different 
programmer. Points of cooperation and communication among programmers include only the. speci- 
fied interfaces among modules. Minimizing the number and i aca of interfaces reduces 8 Project 
administration costs. : | Joy ee 


e Structured testing. Testing of the whole system is simples when you sues modules’ SO ‘that each 
can be tested by itself, before testing its interactions with other modules. ie. 2 


e Flexibility. When you can anticipate changes to the system, you can limit the effects of the ohanwes 
on other modules by isolating the areas of a ae ene in a module. 


Only the first of these criteria is s significant to XOS, but al se be applicable to ae operating system 
design. 
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Modules are relevant to binding in that they (indirectly) define the units that can be distributed among 
physical segments. A module is a single compilation unit. Intel’s translators divide each compilation 
unit into logical segments. Each logical segment is a named object that can be assigned to a physical 
segment. You can use the development tool Binder to combine more that one logical segment into a 
physical segment. 


Segmentation — 
Protection requirements partially dictate how to distribute modules among physical segments: 


e Data and procedures of different privilege levels must reside in different physical segments. 


¢ Data and procedures of one task must reside in different segments from those of other tasks unless 
sharing is explicitly intended. 


° Instructions must reside i in different physical segments from writable data items. 


¢ Data structures for which you wish to provide individual protection (for example, the semaphores 
and mailboxes discussed in Chapter 5) must each be ina ecparale sceinent. 


Operating system procedures that have the same privilege level and are “haps via the GDT « can be 
combined in just one segment (assuming that the total size does not exceed 64K bytes). In fact, doing 
so has two advantages: all intermodule calls can be implemented as'short CALL instructions, avoiding 
the additional processing associated with changing the contents of the CS register, and more GDT slots 
are available for other purposes. Of the procedures in XOS, the level-zero procedures presented in 
Chapters 3 thru 5 can be combined in one segment, while the level-one I/O interface procedures can 
go in another segment. Each device-driver task has its own code, data, and stack segments. 


Interfaces 
Possible mechanisms for implementing the interfaces among modules are 


e Intrasegment (short) references. References: to data or procedures in the same segment are most 
efficiently implemented when you can use the current contents of a segment register. 


° Intersegment (long) references. References to data or procedures i ina segment 1 not currently indicated 
by one of the segment registers must cause a segment selector to be loaded into a segment register. 

- Intersegment references permit sharing of functions among many modules and. permit access to 
functions at another privilege level. : 


e Sharing by value. Procedures and data can be shared by including a cas of the data or - procedures 
- in the same unit (segment or task, as appropriate) as each procedure that uses them. While this 
-approach ‘can yield more efficient execution in some cases, it has limited applicability. It is usually 
best to share dynamically changing data by name, so that all the procedures that use it can obtain 
the most up-to-date version. Sharing large or widely used data or procedures by name uses main 
-memory more efficiently. _ 


e Sharing by name. The “ ‘name” referred to here is the acsirio tor of the shared data or procedure. 
-Chapter 5 discusses methods of shane by name eae GDT, common LDT, and pa 


In XOS, all tasks share the se onients of thie etal aad I / ered senieiits via the GDT. asian 
tions procedures use long calls to access:the primitives in these segments..Calls within the kernel level 
or within the I/O level to private procedures at the same level are short calls. 
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Naming 


The names by which you reference the components of a system influence the way the en can be 
bound. Classes of names over which you have some degree of control are : 


¢ Modules. Builder uses the name of a module to represent all sabligs or all segments within the 
module. Debuggers use module names to qualify identifiers of variables and procedures. 


¢ Logical segments. The choice of logical segment names determines the possibilities for segment 
_ combination. Binder combines logical segments that have the same name as well as compatible 
combine-types.. 


e Physical segments. The names of physical segments give you the ability to assign segment attributes 
individually using the Builder. 


© Publics. Public identifiers must be unique among the modules that are bound Beetice 


e Gates. Gate names identify the entry points to procedures. You can use gate names to give entry 
points different public names than those used in the source language. 


Timing — 


With respect to time, you can rate bindings on a scale running from early to late. An example of early 
binding is a compiler’s assignment of segment-relative locations to procedures and data. The latest 
binding is that accomplished by the processor as it adds a segment-relative location to the 24-bit base 
address of the segment. Between these extremes are other opportunities for binding: | 


¢ Post-compile-time. Through Intel’s utilities Builder and Binder, you can. combine segments, resolve 
intersegment references, allocate descriptor table slots, and aliceate memory. 


¢ Load-time. The loader can incorporate various levels of binding. 


a. If the object module contains fix-up information (as in a linkable module), the wader can bind 
__ all references as it loads the segments of a task. | ' 


_b. The call gates of the iAPX 286 architecture make it possible for the loader to efficiently resolve 
references to predefined classes of procedures (to operating system primitives, for example) at 
the time a program is being loaded. This chapter presents an example of this form of load-time 
binding in a later section. 


e Run-time. Call gates also permit binding to an executable segment at the time it is first referenced. 
By resetting the present bit in a call gate to an unloaded segment, you ensure that a trap will occur 
when the gate is used. The “not present” trap handler can then load the teduired segment, allocate 

a descriptor for it, and fix up ane call: age 7 3 


IMPLEMENTING ACCORDING TO THE MODEL 


With a binding model in mind, consider how to implement that model during the various stages of 
system development: in source code, by transistors, by binding utilities, by loaders, by the operating 
system, and finally by the processor itself. fy : | 
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The model behind the example operating system, XOS, includes these components: 


¢ Each module contains functionally | related data structures and procedures. 


¢ One segment contains level- -Zero (kernel). procedures, another segment. contains leery -zero acy 
another segment level-one (I/O) procedures, and another level-one data. Operating system tasks 
(such as device drivers) have their own distinct segments. 


» The GDT contains descriptors of kernel and I/O segments, making them sharable by all. tasks. 
Gates for operating-system primitives, however, reside in the LDTs of the tasks that use them. 


¢ The segment. names created by PL /M-286 set the standard for segment naming in general. (Refer 
to the chapter entitled “Linking to Modules Written in Other Languages” in the PL/M-286 User’ S 
Guide for definition of PL/M-286 segment sib 


¢ Tasks will be loaded dynamically. 


¢ lLoad-time binding to XOS primitives is an option. (Ths is one reason for placing gates for operating 
system primitives in LDTs.) mae | , 


Source Code 

Since some of the logical segments declared in assembly language may be combined after assembly by 
the Builder, the assembler needs to know whether the object of an external reference will be in one of 
those segments whose descriptors it assumes to be loaded in segment registers. If the reference is to 
another segment, the assembler must emit instructions that change the contents of a segment register. 


The programmer supplies this information via additional assembly nevane ees A variety of. forms 
are available for this purpose, such as. | i | | 


SEGMENT 
ASSUME 
NEAR and FAR variantsof PROC and LABEL 
segment overrides (for exraple ES: TABLE TTEM) | 


(Refer to the ASM 286 Askew Language Reference Manual for details on the use of these items. ). 


The module. DISP containing the dispatcher is the only kernel module of XOS written in assembly 
language (refer to Chapter 4). The logical code segment has the nnme NUCLEUS_CODE and combine 
type ER so that it will combine with PL/M-286 segments of the same name. This module has no logical 
data segment. The procedure DISPATCHER is a NEAR procedure because only other kernel proce- 
dures i in n the same physical segment call it, 


Compilers 


With PL/] M- -286, decisions venandiie cain are. not panbedded in source. code. but rather are 
implemented by the compiler according to compiler control statements that you supply. (Refer to the 
SMALL, COMPACT, LARGE, and extended segmentation controls in the PL/M-286 User’s Guide.) 
With these control statements, you have nearly as much control over system structure as with assembly 
language, but changes in system structure do not require changes to source code. It is just as mnporant 
however, that use of these controls conform to a consistent model of system structure. oe 


Figure 11-1 shows the segmentation controls used for compiling the kernel modules of XOS. These 
controls define a subsystem named NUCLEUS that contains all the PL-O modules of XOS. The 
PL/M-286 compiler prefixes the names of the code and data segments with the subsystem name. The 
list of exports includes all the primitives. For each of the procedures named in the exports list, the 
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COMPACT (NUCLEUS HAS 


SLOT 
GATE 
DISPATCHER 


_ SEMAPH 


INTRUPT | 
DESCRIPTOR 
DISQUE 


EXPORTS 


RESERVE_SLOTS 
ALLOCATE 
CREATE ALIAS 
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MEMORY 
ALIAS 


MAILBOX 


TASK 
GATE 
MESSAGE 


RELINQUISH SLOTS 
FREE SEG 
CHANGE_AR 


SIGNAL SEMAPHORE 
RECEIVE MESSAGE 
CREATE TASK 

LOAD LDT_ GATE 


WAIT SEMAPHORE 

SEND MESSAGE 

CREATE LDT 

LOAD LDT 

GET GATE POINTER 
ATTACH TO INTERRUPT 


$ 
$ 
$ 
$ 
$ 
$ 
$ 
S 
$ 
$ 
$ 
$ 
$ 
$ 
$ 
$ 
$ 
$ 


WAIT FOR_INTERRUPT 


Figure 11-1. Subsystem for Kernel Exports 


compiler generates a long RET instruction at the end of the procedure or at RETURN statements. 
This enables procedures in other segments to call the the kernel procedures. The keyword COMPACT 
tells the compiler to generate short RET instructions for procedures not named in the export list. 


Binding Utilities 


Intel’s iAPX 286 Binder (BND286) and System Builder (BLD286) provide a variety of binding services, 
including 


e Combining logical segments that have the same name and combine type 
¢ Resolving references among modules 

e Constructing templates for GDT, LDT, and TSSs 

e Allocating memory for bootloadable portions of the system 

e Assigning access rights to segments 
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¢ Constructing gates 
e Formatting object files for the convenience of boot loaders and dynamic loaders 


e Creating export modules that contain gates for operating-system interfaces 


Figure 11-2 shows the Binder specifications that combine the level-zero modules of XOS. The input 
modules contain only three unique segment names (the PL/M-286 names: NUCLEUS_CODE, 
NUCLEUS_DATA, and STACK); therefore, the output module contains just three segments: one for 
instructions, one for static data items, and one for the level-zero stack. The name of the output module 
is NUCLEUS; it is written to the file NUC.LNK. Similar specifications combine the level-one modules. 


Figure 11-3 shows the specifications to build a bootloadable file for the example operating system. The 
SEGMENT statement assigns privilege levels to to each of the segments; scemenis not mentioned in 
this clause receive privilege level 3 (PL 3) by default. , 


The TABLE statement defines the descriptor tables. The RESERVE clause allocates space for the 

working descriptors used by such modules as the memory-management module described in 

Chapter 3. The ENTRY clause identifies the remaining segment re that belong in each table. 
Builder allocates slots for each of these ee | 


The TASK statement provides information for contructing TSSs. The identifier assigned to each task 
is the identifier of the descriptor of its TSS. The OBJECT clause identifies the module containing the 
information Builder can use to fill the segment-register and initial stack fields of the TSS. 


The GATE statement creates gates for each of the public procedures that are XOS primitives, assigns 
a privilege level to each gate, and gives each a name different from the procedure name. 


The EXPORT statement creates a linkable module KERNEL in file XOS.EXP that application modules 
can use for binding to the gates for XOS primitives. 


RUN :F2:BND286 & 

sF1:POINT.OBJ , :F1:SLOT.OBJ, & 

>F13:MEMORY.OBJ, sF1l:DISP.OBJ, & 

>F1l:ALIAS.OBJ , sF1l:SEMAPH.OBJ, & 

>F1:MBOX.OBJ :FLsINTRPT.OBJ, & 
& 
& 
& 


v 
;FL3:DESCR.OBJ ,. :F1:DISQUE.OBJ, 
’ 


:Fl:TASK.OBJ ‘sF1:MESSAG. OBJ, 
PLM286.LIB 


NAME (NUCLEUS) OBJECT (:F1:NUC.LNK) NOLOAD DEBUG 


Figure 11-2. Binder Specifications for XOS Kernel 
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Ssystem-ID 
INPUT FILES: 


OUTPUT FILE: 


BUILD FILE: 


WODIRDRU RW pH 


i1APX286 SYSTEM BUILDER, 


:F1:NUC.LNK, 
:F2:LARGE.LB2, 
:F1:xOS 
CONTROLS SPECIFIED: 


BINDING AND LOADING 


OBJECT (:F1:xX0S) 


:F1:X0S.BLD 
EXAMPLE OS; 


SEGMENT 


NUCLEUS CODE 
NUCLEUS DATA 
NUCLEUS. STACK 
URTASK_CODE 

URTASK DATA 
URTASK. STACK 

LQ PLM286 LIB CODE 
LARGE_V1P@.STACK@ 
LARGE _V1P@.STACK1 
LARGE _V1P@.STACK2 
CONSOLE DRIVER_CODE 
CONSOLE DRIVER DATA 
CONSOLE DRIVER.STACK 
CONSOLE STACK@ 
LOADER STACK@ 


GATE 
XQ ATTACH TO_INTERRUPT 
XQ _ WAIT _FOR INTERRUPT 


XQ_ ~ RESERVE _SLOTS 
XQ_ _RELINQUISH_ SLOTS 
XQ | ~ ALLOCATE 

XQ FREE SEG 

XQ CREATE _ALIAS 

XQ CHANGE _AR 

XQ WAIT _ SEMAPHORE 
XQ. ~ SIGNAL _SEMAPHORE 
XQ SEND MESSAGE 


XQ_ RECEIVE _MESSAGE 


XQ CREATE _LDT 

XQ CREATE _ _TASK 

XQ | LOAD __ LDT 

XQ | LOAD _ ~LDT _GATE 

XQ | GET GATE POINTER 


Vx.y 


(DPL=@), 

(DPL=0), 

(DPL=0, LIMIT=+290), 
(DPL=@) 
(DPL=@) 
(DPL=9, LIMIT=+2@6H), 
(DPL=@, CONFORMING), 
(DPL=9) 
(DPL=1) 
(DPL=2) 
(DPL=1) 
(DPL=1) 
(DPL=1, LIMIT=+26), 
(DPL=6, LIMIT=+2@), 
(DPL=6, LIMIT=+2@); 


=~ * 


~ 32 UN 


(ENTRY=RESERVE SLOTS, 
(ENTRY=RELINQUISH SLOTS, 
(ENTRY=ALLOCATE, 
(ENTRY=FREE SEG, 
(ENTRY=CREATE ALIAS, 
(ENTRY=CHANGE AR, 
(ENTRY=WAIT SEMAPHORE, 
(ENTRY=SIGNAL SEMAPHORE, 
(ENTRY=SEND_ MESSAGE, 
(ENTRY=RECEIVE_MESSAGE, 
(ENTRY=CREATE LDT, 
(ENTRY=CREATE TASK, 
(ENTRY=LOAD _LDT, 
(ENTRY=LOAD LDT GATE, 
(ENTRY=GET GATE POINTER, 


TIME SLICE ° (INTERRUPT, DPL=9, ENTRY= TIMINT); 


TABLE 


GDT (RESERVE=(4..9), 


ENTRY= ( 


NUCLEUS CODE, 
NUCLEUS DATA, 
NUCLEUS. STACK, 

LQ PLM286_LIB CODE, 
LARGE _V1P@. STACK, 


Figure 11-3. Builder Specifications for XOS 
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(ENTRY=ATTACH_TO_ INTERRUPT, 
(ENTRY=WAIT _FOR _INTERRUPT, 


:Fl:URTASK.OBJ, :F1:CONSOL.OBJ, :F1: LOADER.LNK, 
tFl: STACKS. OBJ 


TITLE (Example 0.S.) BOOTLOAD BUILDFILE(:F1:X0S. BLD) 


DPL=1l), 
DPL=1l), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
DPL=3), 
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LARGE _V1PQ.STACKG, 
LARGE V1P@.STACKI, 
LARGE V1P0.STACK2 


) 
), | 
URTASK LDT (ENTRY=(URTASK)), 
CONSOLE LDT (ENTRY=(CONSOLE DRIVER, CONSOLE _STACK@)), 
LOADER TASK LDT (ENTRY=(LOADER, LOADER STACKG@)), — 
IDT (ENTRY=(15: TIME SLICE) ); 


TASK 

ADAM (INITIAL, OBJECT 
LDT 

CONSOLE DEVICE (OBJECT 
LDT 
STACKS 

LOADER TASK (OBJECT 
LDT 
STACKS 


URTASK, 
URTASK_LDT), 
CONSOLE DRIVER, 
CONSOLE LDT, 
(CONSOLE STACK@)), 
LOADER, 

LOADER TASK _LDT, 
(LOADER_STACK®@) ); 


EXPORT #:F1:XOS.LB2 (KERNEL ( 
XQ RESERVE SLOTS, 
XQ RELINQUISH SLOTS, 
XQ ALLOCATE, 
XQ FREE SEG, 
XQ CREATE ALIAS, 
XQ CHANGE AR, 
XQ WAIT SEMAPHORE, 
XQ SIGNAL SEMAPHORE, 
XQ_ SEND. MESSAGE, 
XQ RECEIVE MESSAGE) ); 


END 


BUILD FILE PROCESSING COMPLETED 


Figure 11-3. Builder Specifications for XOS (Cont’d.) 


These specifications do not illustrate all the features of Builder; refer to the iAPX 286 System Builder 
User’s Guide for a complete description of Builder syntax. 


OVERVIEW OF LOADING 


The loader in a dynamic system is not only responsible for copying a program into main memory, but 
is also a step in the binding process. A loader installs the actual TSS and LDT for a task, thereby 
making it possible for the processor to interpret the task’s memory references. 


If all symbolic references are already resolved, a loader’s work is simple. The 1APX 286 object module 
format (OMF) organizes. scement information to facilitate rapid loading with little decision-making by 
the loader program. 7 
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Converting a Program Into a Task: 
Before an operating system can switch control to a new task, these structures must be initialized: 


¢ The TSS (data the processor needs in order to run the task). 
¢ The task database (TDB) (data the operating system needs in order to run the task). 


Either the following” structures must be present ¢ or some mechanism must be in place to make them 
present when necessary: 


e Stack segments for each privilege feel at which the task runs. (A stack-fault andles could 
automatically allocate a stack the first time it is used. ) 


» Executable and data segments. (A virtual. memory system: could make these present when referenced. ) 


Most programs also need a LDT to contain descriptors fi segments avivate to the ale An LDT is 
not required, however, if all descriptors used by the task reside in the GDT. 


The initial values in the CS:IP fields of the TSS should point to the entry point of the first procedure 
of the new task. 


STYLES OF LOADERS . 
There are several ways to structure a loader. The following are just a few examples: 


1. Asa separate and permanent task. With such a structure the loader constructs data segments in 

~~ the format of the new task’s TSS and LDT. To create the new task, it passes descriptors for these 

~ segments to privilege-level 0 (PL-0) procedures that convert them to system segments and start 
the new task. 


2.° As procedures that run within an existing task. This approach suits the UNIX EXECUTE function, 
where the FORK function creates the task in which the loader runs as a duplicate of the task that 
called the FORK function. The loader deletes the descriptors it finds in the task’s LDT (thereby 
deleting the associated segments unless aliases exist:in other tasks) and creates new descriptors 
for the segments it loads. | | 


3. As procedures in a skeletal task created by the operating-system kernel. The loader has only to 
a allocate an /LDT and install BeseMpIors OF ne anode: it loads. 


For approaches 2 and 3, the procedures of the loader may have segment Gescniprors and eae in the 
GDT so as not to encumber the LDTs. 


KERNEL SUPPORT 


A loader normally runs at PLs 2 or 3 because it uses of both kernel-level procedures (for example, 
ALLOCATE to create a segment for the new task) and PL-1 procedures (for example, the I/O proce- 
dures to read object modules from. disk).-However, task creation involves some functions that only 
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PL-0 procedures can execute. For these functions the operating system must provide some. additional 
support. These functions include : 


¢ Changing the access rights byte of a descriptor. The loader can create a writable data segment 
(using a level-O procedure such as the ALLOCATE procedure described in Chapter 3) into which 
to read a segment from the object file of the program being loaded. But, if that segment is to have 
some other type in the new task (the segment might be an executable segment, for example), the 
access rights byte must be changed. 


¢ Filling the new task’s LDT with the base addresses of its segments. When the loader allocates a © 
segment for the new task, the ALLOCATE procedure places the physical base address of the segment 
in a descriptor table (presumably the loader’s LDT, but possibly the GDT). Only PL-0 procedures 
should have access to physical addresses in descriptor tables. 


¢ Allocating the stack segment for PL 0. Insufficient space in this segment can. cause failure of PL-0O 
procedures. Also, if the kernel requires the TSS to be located in the PL-0 stack segment (as suggested 
_in Chapter 4), then the kernel should handle the complexities of setting up such a structure. 


¢ Initializing the task database (TDB) for the new task. Only PL-O proceoures have access to this 
- data structure. (Refer to Chapter 4 for a discussion of the task database.) © 


¢ Entering the new task in the scheduling queues and setting the back- link re nested task flag in the 
new TSS. These oe ae are crucial to proper functioning of the scheduler and therefore should 
be done at PL 0. | , 


iAPX 286 Object Module Format 


Intel has defined object module formats (OMFs) for the iAPX 286 to be used by translators, object- 
program utilities, and loaders. There are two classes of object module: 


8 Linkable modules, which are produced by translators and consumed by Builder dnd Binder. Binder 
. can also produce a linkable module from one or more input linkable modules i in a process known as 
incremental binding. : 


¢ Loadable modules, which are produced by the Binder and the Builder and consumed by loaders and 
eeeleee | | 


Refer to. the iAPX 286 System Builder l User’s Guide for detailed definitions of the iAPX 286 Object 
~Module Format. 


Loaders that adhere to Intel’s OMFs for loadable modules can load object modules created by Intel’s 
program development tools. There are two basic variations of the iAPX 286 OMF for loadable modules: 


o- That created by the Binder supports sieaohttanward. single- task snodules: 


¢ That created by the Builder supports more complex variations, including multitask modules with 
shared segments (possibly including shared LDTs), reserved LDT locations, GDT descriptors to be 
installed as the task is loaded, etc. 


Builder not only produces modules intended for use by dynamic loaders but also produces bootloadable 
modules designed for use by bootstrap or initializing loaders. Bootloadable modules use absolute 
addresses. A boot loader must be able to write to absolute physical locations. : 
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The OMF of each object module consists of a header followed by a sequence of sections of various 
kinds. The sections relevant to this discussion are those in loadable modules, including © 


¢ DESCRP: contains all the descriptors for the module. A loader can use this section as a template 
for the LDT. 


e LODTXT: contains the data and instructions to be loaded. A loader fills allocated memory segments 
from the records of LODTXT. 


¢ DESNAM: provides symbolic names for segments. A loader can use these symbolic names to provide 
a load-time interface for making changes to segment parameters (for example, decreasing segment 
limit of an expand-down stack segment to provide more stack space). 


Flow of Loader 


A ieades must take different action depending on whether the loadable nodules are decatee by the 
Binder or by the Builder. The main difference in loading the two types of OMF is the source of infor- 
mation for descriptor tables. In the case of Binder OMFs, the DESCRP section is in the format of an 
LDT. In the case of Builder-created OMFs, information for the GDT, IDT, and LDTs comes from 
various LODTXT records. A Boolean in the header of a loadable module Sihneulshes between Builder- 
created and Binder-created modules. 7 


FLOW FOR BINDER-CREATED MODULE 


1. Allocate space for LDT segment. The size of dies deiaent is eight times the value of the descriptor 
count field of the module header. Put LDT descriptor i in GDT. a 


2. Read the DESCR section into the LDT segment. 


\. 


3. Allocate space for all segments specified in the LDT, updating the Bases sdiivess fields. 

4. Allocate space for the TSS. (Step 3 does not allocate the TSS because the DESCR section meee 
not contain a TSS descriptor.) Put TSS descriptor in GDT. | . 

5. Read first LODTXT section into TSS segment. (The first LODTXT record is always ; a TSS. ) 

6. Put LDT selector into TSS. 

7. If the LODTXT section is exhausted, the re is somoletely loaded. Juinp to the TSS. 

8. Read next LODTXT record into proper segment. Go to step 7. 


FLOW FOR BUILDER- CREATED MODULE 


Allocate seniporary space to hold all entries from the DESCRP section. 
Read the DESCRP section into this space. 

Allocate physical segments for all DESCRP entries (except for gates). _ 
Read beginning of LODTXT record. | | | 


_ Examine descriptor name of LODTXT record. The selector name is either a special identifier for 
the GDT or I[DT, or it is an index into the DESCRP entries. The type field of a DESCRP entry 
distinguishes LDT segments from other types. 


a. If the LODTXT record defines entries of the GDT, then, for each ently in the ‘record, obtain 
the descriptor from DESCRP and install it in the GDT. | 


b. If the LODTXT record defines entries of the IDT, then, for each entry in “the cone: obtain 
the descriptor from DESCRP and install it in the IDT. - 


Sh Ee oS) 
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cc. If the LODTXT record defines an LDT, then, for each enUty in rie record, obtain the descrip- 
tor from DESCRP and install it in the LDT. 


o If the LODTXT record does not apply to a descriptor table, read the LODTXT record directly — 
“into the selected segment. os 


If more LODTXT records remain, £0 to ae 4, 
Free the space used for DESCRP entries. 
8. . The task or tasks are loaded. Jump to the TSS identified in the module header. 


LOAD-TIME BINDING 


As with any system, it is possible on the iAPX 286 to delay many binding operations until load time 
by incorporating binding functions into the loader. The call gates of the iAPX 286 architecture, however, 
provide an especially convenient and efficient way to delay one,.specific binding operation: namely, 
binding. of calls to operating- ace primitives. Load-time binding to operating-system primitives is an 
aennES when . . 


°. The opecating: systeni 1S. under. development: aha GDT locations of operating-system segmnelit 
descriptors are subject to change 7 


e Programs may execute under different operating systems that aie different GDT layouts 
Data structures for yap eee load-time panes are 


° AL eeport soda be specially canted sin wares for operating system primitives. Figure 11-4 
shows how you can create such a module through Builder specifications. The NOT PRESENT 
specification marks the gates by resetting the present bit. Gates used for this purpose must reside 
in the LDT so that Binder (which works only with LDT descriptors) can use them. You need to 

_ update this export file only when you change the number or names of operating-system gates. 


¢ A table of actual gates for the operating-system primitives. This table must contain, for each primi- 
tive, the gate name, a GDT selector for the segment in which the primitive resides, and the entry 
point (offset) within the segment. It is most convenient to take such information from a Builder 
export file that exports the gates for operating-system nes The example specifications shown 
in figure 11-3 create such an export file. | a oi : 


Figure 11-5 shows the data flow for load-time binding. By using the gate name from the DESNAM 
section, the loader associates a marked gate in the LDT with its gate name. Given the gate name, it 
looks up the actual binding information. 2 eo 


EXAMPLE LOADER 


Figure 11-6 shows an example of a loader that reads the iAPX 286 OMF, resolves references to 
operating-system primitives, and calls kernel procedures to create a new task. In the interest of simplic- 
ity, this ey recognizes pony! the emer OMF produced.by the Binder, and all error EP Ceerine 
is omitted... oo, , : 


This loader calls the kernel procedures CREATE_LDT, LOAD_LDT, LOAD_LDT_GATE, | 
CREATE_TASK, RESERVE_SLOTS, and CHANGE_AR, which are not shown. CREATE_LDT 

allocates an LDT segment for a new task and installs its descriptors in two of the four GDT slots 
specified by TASK.SEL. LOAD_LDT transfers.a descriptor from the LDT of the loader to the LDT 
of the new task. LOAD_LDT_GATE places a gate in the LDT of the new task. CREATE_TASK 
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system-ID 


INPUT FILES: 
OUTPUT FILE: 
CONTROLS SPECIFIED: 


BUILD FILE: 


OMANI HAUS WN FE 


BUILD FILE 


BINDING AND LOADING 


1APX286 SYSTEM BUILDER, 


:F1l:NUC.LNK 
(none) 


:F1:XOSGAT.BLD 
EXAMPLE OS; 


SEGMENT NUCLEUS CODE 


Vx.y 


(DPL=@), NUCLEUS DATA 


NUCLEUS. STACK (DPL®= 8); 


GATE 
XQ RESERVE SLOTS 
XQ RELINQUISH SLOTS 
XQ ALLOCATE — 
XQ FREE SEG 
XQ CREATE ALIAS 
XQ CHANGE AR 
XQ WAIT SEMAPHORE 
XQ SIGNAL SEMAPHORE 
XQ SEND MESSAGE 
XQ RECEIVE MESSAGE 


TABLE 


GDT (ENTRY=(NUCLEUS CODE, 


DUMMY (ENTRY= ( 
XQ RESERVE SLOTS, 


(ENTRY=RESERVE_ SLOTS, 


(ENTRY=RELINQUISH SLOTS, 


(ENTRY=ALLOCATE, 
(ENTRY=FREE SEG, 
(ENTRY=CREATE_ ALIAS, 
(ENTRY=CHANGE AR, 
(ENTRY=WAIT SEMAPHORE, 


(ENTRY=SIGNAL SEMAPHORE, 


(ENTRY=SEND MESSAGE, 
(ENTRY=RECEIVE MESSAGE, 


NUCLEUS_DATA, 


XQ _ RELINQUISH _ SLOTS, 


XQ _ALLOCATE, 
XQ FREE SEG, 

XQ CREATE _ALIAS, 
XQ ~ CHANGE _AR, 


XQ WAIT SEMAPHORE, 


XQ SIGNAL SEMAPHORE, 


XQ SEND — MESSAGE, 


XQ _ ~ RECEIVE _MESSAGE) ) ; 


EXPORT #:F1:XOSGAT.LB2 (KERNEL ( 


XQ RESERVE SLOTS, 


XQ _RELINQUISH_ SLOTS, 


XQ ALLOCATE, 
XQ FREE SEG, 
XQ CREATE ALIAS, 
XQ CHANGE AR, 


XQ_ WAIT _SEMAPHORE, 


XQ __ SIGNAL _SEMAPHORE, 


XQ SEND MESSAGE, 


XQ RECEIVE MESSAGE) ); 


END 


PROCESSING COMPLETED 


(DPL=@), 


DPL=3, 
DPL=3, 
DPL=3, 
DPL=3, 
DPL=3, 
DPL=3, 
DPL=3, 
DPL=3, 
DPL=3, 
DPL=3, 


Figure 11-4. Specifying Dummy Gate Exports | 


q=13 


NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 
NOT 


NUCLEUS.STACK)), 


TITLE (Gates for Load-Time Binding) NOBOOTLOAD NOOBJECT 
BUILDFILE(:F1l:XOSGAT.BLD) PRINT (:F1:XOSGAT.MP2) 


PRESENT) , 
PRESENT) , 
PRESENT) , 
PRESENT) , 
PRESENT) , 
PRESENT) , 
PRESENT) , 
PRESENT) , 
PRESENT) , 
PRESENT) ; 
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EXPORT FILE 
APPLICATION OF MARKED GATES 
MODULES FOR 0O.S. PRIMITIVES. 


BND286 
BINDER 


EXPORT FILE 


axa Para OF ACTUAL GATES» 
. FOR O.S. PRIMITIVES 
APPLICATION | 


BINDING. | 
LOADER 


TASK BOUND 


TO 
OPERATING 
SYSTEM 


Figure 11-5. Strategy for Load-Time Binding 
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finishes creation of the new task by creating a TSS from a template in the loader and placing the new 
task in the scheduler’s queues. RESERVE_SLOTS uses techniques such as those illustrated in 
Chapter 2 to allocate descriptor table slots. CHANGE_AR is used to place the correct type code into 
the writable data-segment descriptor used by the loader to fill a segment. 


The module BOND (shown in figure 11-7) shows the handling of the table of actual gates for operat- 
ing-system primitives. The procedure GET_LOAD_FILE is not defined here. It simply fetches the file 
specification for a loadable module from, for example, the console or the command line interpreter. 
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PL/M-286 COMPILER 960-515 date _ . PAGE.= «1° 


System-ID PL/M-286 VxX.y COMPILATION OF MODULE LOADER 
OBJECT MODULE PLACED IN :F1:LOADER.OBJ 
COMPILER INVOKED BY: PLM286.86 :F1:LOADER.PLM DEBUG 


S PAGEWIDTH(71) TITLE('960- 515' ) 
S INCLUDE (:F1:NUCSUB. PLM) 
= S NOLIST . 
S INCLUDE (:Fl: UDISUB. PLM) 
= $ NOLIST 
S$ COMPACT 
1 LOADER: DO; 
AIO OIG ICIIIOIIGICICIOIGIOIGI ICI GIOI III ICICI IOI III 7 
/* Language Extensions * / 
2 di -DECLARE BOOLEAN | LITERALLY ‘BYTE', 
FALSE LITERALLY ‘'@', 
TRUE... LITERALLY '@FFH', 
TOKEN LITERALLY "WORD', . 
CONNECTION LITERALLY ‘'TOKEN', 
OFFSET LITERALLY ‘WORD', 
FOREVER LITERALLY ‘WHILE. ‘TRUE'; 
OOOO OGIO III CIGIGIOIOIIOIGI GIGI CICS ICICI CI CICIOIIOIOIOI IIT ICO IGIC/ 
/* Externals * / 
| RESERVE SLOTS: PROCEDURE (TABLE,COUNT,SLOT PTR,EXCEP_PTR) 
EXTERNAL; : a ; 
4 2 DECLARE TABLE WORD, COUNT WORD, (SLOT PTR,EXCEP PTR) 
POINTER; - ; 
5 2 END RESERVE _SLOTS;_ 
6 1 CHANGE AR: PROCEDURE (SLOT,RIGHTS, EXCEP PTR) EXTERNAL; 
7 2 DECLARE SLOT SELECTOR, RIGHTS BYTE, EXCEP PTR POINTER; 
8 2 END CHANGE AR; _« 
9 1 ALLOCATE: PROCEDURE (SLOT, RIGHTS, SIZE, EXCEP PTR) 
EXTERNAL; . 
1d 2 DECLARE SLOT SELECTOR, RIGHTS BYTE, SIZE WORD, 
EXCEP_ PTR POINTER; _ | | . 
ll 2 END ALLOCATE; . 
12 1 FREE SEG: PROCEDURE (SLOT, EXCEP_PTR) EXTERNAL; 
13 2 _DECLARE SLOT ReURee EXCEP_PTR POINTER; 
14 2 END FREE_SEG; | a ie 
15 an CREATE LDT: PROCEDURE (TASK SEL, SIZE, EXCEP PTR) EXTERNAL;. 
16 2 DECLARE TASK_SEL Senora SIZE WORD, EXCEP_ PTR POINTER; 
17 2 END CREATE _LDT; ; me 
18 1 LOAD_LDT: PROCEDURE (TASK SEL, NEW SLOT, OLD SLOT, 
EXCEP _PTR) EXTERNAL; 
19 2 DECLARE (TASK _ SEL, NEW “SLOT, OLD SLOT) SELECTOR, 


EXCEP_PTR POINTER; 


Figure 11-6. Binding Loader — 
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PL/M-286 COMPILER 966-515 date PAGE 2 
28 (2 END LOAD_LDT; 
21 ol LOAD_LDT_GATE: PROCEDURE (TASK SEL, NEW SLOT, RIGHTS, 
TARGET, COUNT, EXCEP PTR) EXTERNAL; 
22. 2 DECLARE (TASK SEL, NEW SLOT) SELECTOR, RIGHTS BYTE, 
(TARGET, EXCEP_PTR) POINTER, COUNT BYTE; — 
23. 2 END LOAD LDT GATE; — 
24 «1 CREATE_TASK: PROCEDURE (TASK_SEL, TEMPLATE, PRIORITY, 
EXCEP PTR) EXTERNAL; 
25. 2 DECLARE TASK_SEL SELECTOR, (TEMPLATE, EXCEP_PTR) 
POINTER, PRIORITY BYTE; 
26 2 END CREATE TASK; 
27.1 GET_LOAD FILE: PROCEDURE (FILE_SPEC_PTR) EXTERNAL; 
2802 DECLARE FILE SPEC PTR POINTER; 
29. (2 END GET LOAD FILE; 
36 BUILD BOND TABLE: PROCEDURE (FILESPEC_PTR, EXCEP_PTR) 
EXTERNAL; ae | 
312 DECLARE (FILESPEC_ PTR, EXCEP PTR) POINTER; 
32.2 END BUILD_BOND_TABLE;~ 
331 FIND_BOND: PROCEDURE (SNAME_PTR, ENTRY_PTR, SEL PTR, 
EXCEP_PTR) EXTERNAL; | | 
342 DECLARE (SNAME PTR, ENTRY_PTR, SEL_PTR, EXCEP_PTR) 
POINTER; | 
35.2 END FIND BOND; 
361 INITIALIZE SYSTEM: PROCEDURE EXTERNAL; 
372 END INITIALIZE SYSTEM; 
38 REPORT: PROCEDURE (EXCEP_PTR) EXTERNAL; 
392 DECLARE EXCEP PTR POINTER; 
492 END REPORT; 
41 1 DOQSATTACH: 
PROCEDURE (PATHS$P, EXCEP$P) CONNECTION EXTERNAL; 
42 2 DECLARE (PATHSP, EXCEP$P) POINTER; 
43 2 END DQSATTACH; 7 
44 1 ‘DQSDETACH: PROCEDURE (CONN, EXCEPSP) EXTERNAL; 
45 2 DECLARE CONN CONNECTION, EXCEPSP POINTER; 
46 2 END DQSDETACH; 
47 1 DQSOPEN: | | 
PROCEDURE (CONN, ACCESS, NUMSBUF, EXCEPS$P) EXTERNAL; 
48 2 DECLARE CONN CONNECTION, (ACCESS, NUMSBUF) BYTE, 
EXCEPSP POINTER; 
49 2 END DQSOPEN; 
56 ol DQSSEEK: PROCEDURE | 
(CONN, MODE, LOCATION, EXCEP$P) EXTERNAL; 
51 2 DECLARE CONN CONNECTION, MODE BYTE, 
LOCATION DWORD, EXCEP$P POINTER; 
52. 2 END DQSSEEK; | " 
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DQSREAD: PROCEDURE 
(CONN, 


~DQSCLOSE: 


date PAGE 


BUFSP, COUNT, EXCEPSP) WORD EXTERNAL; 
DECLARE CONN CONNECTION, COUNT WORD, 

(BUFSP, EXCEPSP) POINTER; - 

END DQSREAD; 


PROCEDURE (CONN, EXCEPSP) EXTERNAL; 
DECLARE CONN CONNECTION, EXCEPSP POINTER; 
END DQSCLOSE; 


3 


AUIS III II III IIIT III III IIIT TI IIIT IATA 


/* 


DECLARE IN_GDT 


IN_LDT © 
DATA _W LITERALLY '11116610B', /* Access rights: 


Data — " 


LITERALLY '‘'@', 
LITERALLY ‘l', 


/ 


present, DPL=3, expand-up, writable, data segment */ 


DATA_WD LITERALLY '11116110B', /* Access rights: 


present, DPL=3, expand-down, writable, data segment */ 


DECLARE 


READ LITERALLY ‘l', 
DEFAULT PRIORITY LITERALLY '4', 
ALLOCATED | LITERALLY '8@H', 
OK LITERALLY ‘'@', 
EXCEPTION LITERALLY ‘ EXCEP<>OK' ; 
PATH NAME (47) BYTE, /* Disk file to load a 
LOAD FILE CONNECTION, 
ACTUAL WORD, 
EXCEP WORD, 
TASK_SLOT SELECTOR, /* First of GDT slots 

: for new task — */ 
DCS_SEL SELECTOR, /* Data or code segment 

; of new task */ 


BOND FILESPEC (*) BYTE 
INITIAL (11, 


'sF1:xXOS.LB2'); 


DECLARE FILE HEADER BYTE; 


DECLARE MODULE HEADER 
TOTAL SPACE 


DESCR_ COUNT 
BUILT 

DATE 

TIME 
CREATOR 
TSS_SEL 


‘DESCRP LOC 


LODTXT_LOC 
IGNORE 1 
DESNAM_LOC 
IGNORE 2 
IGNORE 3 
IGNORE 4 
LAST_LOC 


RESERVED1 


STRUCTURE ( 


DWORD, 
WORD, 
| - BYTE, 
(8) BYTE, 
(8) BYTE, 
(41) BYTE, 
- WORD, 
DWORD, /* @ */ 
- DWORD, /* 1 */ 
DWORD, /* 2 */ 
DWORD, /* 3 */ 
DWORD, /* 4 */ 
DWORD, /* 5 */ 
DWORD, /* 6 */ 
DWORD, /* 7 */ 
DWORD, 
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63 


64 


65 


74 


75 


WwW Wh 


RES ERVED2 -  DWORD); 


/* Table of segment. names from DESNAM weeien of OME */ 
DECLARE DESNAM SEL SELECTOR, 

DESNAM WIDTH LITERALLY '‘4l1', 

DESNAM BASED DESNAM_SEL (2) STRUCTURE ( 

NAME (DESNAM_WIDTH) BYTE y 

DIX WORD; #£=/* Index */ 


/* RAM copy of DESCRP section of OMF */ 
DECLARE DESCRP_SEL SELECTOR, 
SEGDT BASED DESCRP_SEL (2) STRUCTURE ( 


LIMIT WORD, 

LO BASE WORD, ete t 

HI _BASE BYTE, /* Data/code segment descr */ 
RIGHTS: | BYTE, 

RESERVED | WORD Vy 


GATET BASED DESCRP_SEL (2) STRUCTURE ( 
ENTRY POINT OFFSET, 


SEL — SELECTOR, 

WORD_COUNT BYTE, .. /* Gate descriptor */ 
RIGHTS BYTE, 

RES ERVED WORD | > 
LIX a WORD; /* Index */ 


/* Template for Task State Segment for new task */ 


DECLARE TSS STRUCTURE ( 


BACKL SELECTOR, , 

SP@ OFFSET, SS@ SELECTOR, 

SPl OFFSET, SS1 SELECTOR, 

SP2 OFFSET, SS2 SELECTOR, 

IP OFFSET, : 

FLAG WORD, 7 

(AX, CX, DX, BX, SP, BP, SI, DI, 

ES, CS, SS, DS, LDT LINK) SELECTOR ); 


[BERR RRERER ERK RRR ERE KK EKER KK RE KKERKER KEKE RRR EK EK KHEKKERKKKE RK / 
/* - Subroutines ef 


SECTION SIZE: PROCEDURE (TOCIX) DWORD; 


DECLARE. TOCIX WORD; /* Index into Table of Contents */ 
DECLARE TOC(8) DWORD AT (@MODULE_HEADER.DESCRP LOC), 
IX WORD; 


/* Find the size of an OMF section */ 

DO IX=TOCIX+l1 TO 7; 
IF TOC(IX)<>@ /* Skip by null sections * / 
THEN RETURN TOS CREE DOGO aI 

END; 


END SECTION SIZE; 


[BRR RRR RRR RI KIRKE RR RIKER IR IR IR KIKI RR RRR IRA K EK / 
BUILD_DESNAM_ TABLE: PROCEDURE (DESNAM SIZE); 


DECLARE DESNAM_ SIZE DWORD; 
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76 «2 DECLARE DESNAM_ USED DWORD, 
DESNAM_ HEADER STRUCTURE | 
(DESCR_IN WORD, 
NAME LENGTH BYTE); 
qa 2 DESNAM_USED=@; 
/* Allocate a segment for the table */ 
78 2 CALL ALLOCATE (DESNAM SEL, DATA_W, . 
DES NAM _ WIDTH x (MODULE _ HEADER. DESCR _COUNT + 1), @EXCE 
~P); 
79 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
/* Initialize the table */ 
81 2 DO DIX=@8 TO MODULE _ HEADER. DESCR _COUNT; 
82 3 CALL MOVB(@(' ') ,@DESNAM(DIX). NAME(@) ,1); 
83 3 CALL MOVB (@DESNAM(DIX) .NAME(@) , 
SEE hae psnenemonn 
84 3 END; 
/* Read each descriptor name */ 
85 2 DO WHILE DESNAM USED < DESNAM SIZE; 
/* Read fixed portion of DESNAM record */ 
86 3 ACTUAL= DQSREAD (LOAD FILE, @DESNAM _ HEADER, 3, @EXCEP); 
87 3 ‘IF EXCEPTION THEN CALL REPORT (@EXCEP); 
89 3 DESNAM USED=DESNAM _USED+ACTUAL; 
993 DIX=DESNAM HEADER. DESCR_ IN-1l; 
91 3 DESNAM(DIX). NAME (@) =DESNAM _HEADER. NAME LENGTH; 
/* Read rest of name into “table entry */ 
92 3 AG HURES DQSREAD (LOAD _ FILE,@DESNAM (DIX) .NAME(1), 
DESNAM(DIX) . NAME (@), @EXCEP); 
93 3 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
95 3 DESNAM USED=DESNAM _ USED+ACTUAL; 
96 3 END /* DO LOOP * / 
97 2 END BUILD DESNAM TABLE; — 
BRR II TOT ROKK TTI I TIO ROKR IK RIK IIR IK RK RIK ICR KKK IK IKK IK KI / 
98 l LOAD SEGMENTS: PROCEDURE(LODTXT_ SIZE); 
99 2 DECLARE LODTXT SIZE DWORD; 
1@G 2 DECLARE LODTXT_ HEADER STRUCTURE ( 
LOAD OFFSET WORD, 
DESCR_IN WORD, 
LENGTH WORD Vs 
COUNT . WORD, 
LODTXT USED  DWORD; 
101 2 DECLARE NEW_LDT_SEL SELECTOR, 
NEW_ LDT SEL _W WORD AT (@NEW_LDT_ SEL), 
SEG _ RIGHTS BYTE; 
1G2 2 DECLARE TSS_IN LITERALLY 'OFFFDH'; 
193 2 LODTXT_USED=G@; 
/* Step thru all LODTXT records */ 
164 2: DO WHILE LODTXT_USED<LODTXT SIZE; 
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/* Read in the LODTXT header */ 
ACTUAL=DQSREAD (LOAD FILE,@LODTXT HEADER,6,@EXCEP) ; 
IF EXCEPTION THEN CALL REPORT (@EXCEP); 
LODTXT _USED=LODTXT _USED+ACTUAL; 
IF LODTXT _HEADER. DESCR__ IN=TSS_IN 


THEN DO; /* Load the Task State Segment */ 
ACTUAL= DQSREAD (LOAD _ FILE, @TSS, LODTXT HEADER.LENGTH, 
@EXCEP); 
LF EXCEPTION THEN CALL REPORT (@EXCEP); 
LODTXT _USED=LODTXT USED+ACTUAL; 
END /* loading Task State Segment */ 7 


ELSE DO; /* Load a data or code segment */ 
LIX=LODTXT_ HEADER. DESCR_IN- Ls 
IF (SEGDT (LIX). RIGHTS AND @6H) = @6H 
/* expand-down data segment? */ 

THEN SEG RIGHTS=DATA WD; 

ELSE SEG RIGHTS=DATA W; 

/* Allocate a segment */ 
CALL ALLOCATE (DCS SEL, SEG RIGHTS, 

. SEGDT (LIX) .LIMIT+1, @EXCEP) ; 
IF EXCEPTION THEN CALL REPORT (@EXCEP); 

/* Read LODTXT record into segment ~/ 
ACTUAL= DQSREAD (LOAD FILE, 

BUILDSPTR(DCS_ SEL, LODTXT_ HEADER.LOAD OFFSET), 
LODTXT HEADER.LENGTH, @EXCEP); 

IF EXCEPTION THEN CALL REPORT (@EXCEP); 
LODTXT_USED=LODTXT_ USED+ACTUAL; 

/* Put actual access rights in descriptor */ 
CALL CHANGE AR (DCS_ SEL, SEGDT(LIX).RIGHTS, @EXCEP); 
IF EXCEPTION THEN CALL REPORT (@EXCEP); 

/* Construct selector for slot in new LDT */ 

/* DPL = 3; TI = 1 */ 

NEW_LDT SEL_W = (SHL(LIX,3) OR 97H); 
/* Transfer descriptor to new LDT */ 
CALL LOAD _LDT (TASK SLOT,NEW_LDT_SEL,DCS_ SEL, @EXCEP) ; 
IF EXCEPTION THEN CALL REPORT (@EXCEP); 
/* Mark descriptor as allocated */ 
SEGDT (LIX) .RIGHTS=ALLOCATED; 
END /* loading a data or code segment */; 
END /* stepping thru all LODTXT records */; 


END LOAD SEGMENTS; 


OIG IGIICIOISIGIGIOIOIIOISIGISI TOCCOA IOI 
LOAD DESCRP: PROCEDURE; | 


/* Allocate a segment for the DESCRP section * / 
‘CALL ALLOCATE (DESCRP | SEL, DATA _W, 
8*MODULE "HEADER. DESCR _COUNT, @EXCEP); 
IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 
/* Step thru all descriptors */ 
DO LIX = 8 TO MODULE _HEADER. DESCR_COUNT- 13 
/* Read LDT entry */ 
ACTUAL=DQSREAD (LOAD FILE, @SEGDT (LIX), 
8, @EXCEP); 
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145 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
/* Is it marked with Present bit = @ ? */ 
147 3 IF (SEGDT (LIX) .RIGHTS AND 8@H)=@ THEN 
/* Is it a call gate? */ © 
148 3 IF (SEGDT (LIX) .RIGHTS AND @FH)=4 /* Type field * / 
149 3 THEN DO; /* Insert pointer from BOND table */ 
15¢ 4 CALL FIND BOND (@DESNAM (LIX) .NAME, 
@GATET(LIX). ENTRY POINT, @GATET (LIX) .SEL, 
| @EXCEP) ; 
151 4 IF EXCEP=OK THEN /* ee present bit. */ 
152 4 GATET (LIX) .RIGHTS=GATET (LIX) .RIGHTS OR 80H; 
153 4 END /* inserting pointer */; 
154 3 END /* stepping through all descriptors */; 
iss. 2 END LOAD _DESCRP; 
[BRR KKH HKKRE KERR KKK ER EKER / 
of ® Transfer remaining descriptors to new LDT | a7 
156 l ~TRANSFER_REMAINDERS: PROCEDURE; 
/* Handles descriptors for which there was no 
LODTXT record (e.g. stacks and gates). * / 
157 2 DECLARE NEW_LDT_SEL SELECTOR, 
NEW_ LDT _SEL_W WORD AT (@NEW_ LDT _SEL), 
SEG _ _RIGHTS BYTE; | : 
/* Step thru DESCRP entries, shipeine LDT alias */ 
158 2 DO LIX = 2 TO MODULE HEADER.DESCR_COUNT-1; 
159 3 IF (SEGDT(LIX).RIGHTS AND OFH) = 4 
160 3 THEN /* call-gate */ DO; 
/* Construct selector for slot in new LDT */ 
161 4 NEW _LDT SEL_W = (SHL(LIX,3) OR 97H); 
/* Transfer descriptor to new LDT */ 
162 4 CALL LOAD _LDT GATE (TASK SLOT, NEW_LDT SEL, 
GATET (LIX). RIGHTS, 
BUILDSPTR(GATET (LIX) .SEL, 
GATET (LIX) .ENTRY POINT), 
GATET (LIX) .WORD_COUNT, @EXCEP); 
163 4 IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 
165 4 END /* call gate */; 
166 3 ELSE IF (SEGDT(LIX).RIGHTS AND 1@H) <> @ 
167 3 THEN /* unallocated data or code segment */ DO; 
168 4 IF (SEGDT(LIX).RIGHTS AND @6H) = @6H 
/* expand-down data segment? */ 
169 4 THEN SEG RIGHTS=DATA_WD; 
176 4 ELSE SEG RIGHTS= DATA _W; 
/* Allocate a segment */ 
171 4 CALL ALLOCATE (DCS SEL, SEG_RIGHTS, 
SEGDT (LIX) .LIMIT+1, @EXCEP) ; 
172 4 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
/* Put actual access rights in descriptor */ 
174 4 CALL CHANGE AR (DCS_SEL, SEGDT (LIX) .RIGHTS, @EXCEP); 
175 4 IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 


/* Construct selector for slot in new LDT */ 
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/® DPL) = 3; TI = 1. */ 
177.4 NEW LDT SEL W = (SHL(LIX,3) OR O7H); 
/* Transfer descriptor to new LDT */ 


178 4 _ CALL LOAD _LDT (TASK _ SLOT, NEW_ LDT.SEL,DCS _SEL, @EXCEP); . 
179 4 IF EXCEPTION THEN CALL REPORT (GEXCEP); 
181 4 END /* unallocated data or code segment */; 
182 3. ~~ «END /* stepping thru DESCRP entries */; 
183 2 END TRANSFER REMAINDERS; 
FOCI IOIGIGIIOIIGIGIIGIOICICIICIOIGICIIOIICISI ICICI ITI TOK 7 
/* . Main Line aie 
184 l CALL INITIALIZE _SYSTEM; 
185 1. CALL BUILD_ ‘BOND _TABLE (@BOND FILESPEC, @EXCEP); 
186 1 IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 
188 l CALL RESERVE _ SLOTS (IN _LDT, 1, @DCS _SEL, @EXCEP) ; 
189 1 IF EXCEPTION | THEN CALL REPORT (@EXCEP) ;° 
191 1 CALL RESERVE _SLOTS | (IN_- LDT, 1, @DESCRP _SEL, @EXCEP) 3 
192 1 IF EXCEPTION THEN CALL | REPORT (@EXCEP) + 
194 1 CALL RESERVE _SLOTS . (IN _LDT, 1, @DESNAM _ SEL, @EXCEP); 
195 1 IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 
107: 4 DO FOREVER; : 
198. 2 GET NAMES: 
CALL GET: LOAD FILE. (@PATH _NAME); /* May wait */ 
199 2 LOAD _ FILE= DQSATTACH (@PATH _NAME, @EXCEP); 
206 2 IF EXCEPTION THEN GOTO GET ae 
282 2 CALL DQSOPEN (LOAD | _FILE, READ, | @EXCEP); 
203 2 IF EXCEPTION THEN CALL REPORT. ay. 


/* Read file header. */ 
285 2 -ACTUAL=DQSREAD (LOAD FILE, @FILE "HEADER, 1, @EXCEP); 
2 IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 
/* Read loadable-module header */ 


288 2 ACTUAL=DQSREAD (LOAD FILE, @MODULE HEADER, 
. SIZE(MODULE _HEADER) , @EXCEP) ; 
209 2 LE EXCEPTION THEN CALL REPORT (@EXCEP); 
/* Process DESNAM section of OMF * / 
211 2 CALL DQSSEEK (LOAD _FILE,2,MODULE_HEADER.DESNAM_LOC, 
@EXCEP) ; 
212 2 IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 
214 2 CALL BUILD _DESNAM TABLE (SECTION. SIZE(3)); 


/* Tell OS to allocate an LDT */ 


215 2 CALL RESERVE _SLOTS (IN _GDT, 4, @TASK _SLOT, @EXCEP); 
216 2 IF EXCEPTION ~ THEN CALL REPORT (@EXCEP) ; 
218 2 CALL CREATE. LDT (TASK _SLOT, MODULE _HEADER.DESCR COUNT, 
@EXCEP) ; | 
219 2 i 2. wk EXCEPTION. THEN CALL. REPORT. (@EXCEP); 
/* Process DESCRP section */| 
221 a CALL DQSSEEK (LOAD _ FILE,2, MODULE _HEADER.DESCRP _LOC, 


@EXCEP) ; 
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222 2 IF EXCEPTION THEN CALL REPORT oe 
224 2 CALL LOAD _DESCRP; 
/* Process LODTXT es ae 
225 2 CALL DQSSEEK (LOAD FILE,2,MODULE HEADER.LODTXT_ LOC, 
@EXCEP); 
226 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
228 2 CALL LOAD SEGMENTS (SECTION SIZE(1));° 
229 2 CALL TRANSFER REMAINDERS; 
/* Tell OS to create the new task */ 
230 2 CALL. CREATE _TASK (TASK _ SLOT, @TSS, DEFAULT PRIORITY, 
@EXCEP) ; 
231 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
233 CALL DOSCLOSE (LOAD _ FILE, @EXCEP); 


2 

234 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
236 2 CALL DQSDETACH (LOAD_FILE, @EXCEP); © 
237 2 IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 
239 2 CALL FREE SEG (DESCRP_SEL, @EXCEP); 
246 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
242 2 CALL FREE SEG (DESNAM SEL, @EXCEP); 

243 2 IF EXCEPTION THEN CALL REPORT (@EXCEP); 


2452 END /* FOREVER */;. 


: J BH HK KKK RIK KKK HI KHER KK KKK KR ERR KKK KKK KRKEKKEEKEK REE RR / 


246 1 |. END LOADER; 


MODULE INFORMATION: 


CODE AREA SIZE O8B2H -2226D. 


CONSTANT AREA SIZE G9GG1H . 1D 
VARIABLE AREA SIZE QOFFH ‘25904 
MAXIMUM STACK SIZE 9018H 24D: 


508 LINES READ 

@ PROGRAM WARNINGS 

@ PROGRAM ERRORS 
DICTIONARY SUMMARY: 

96KB MEMORY AVAILABLE 

1L1KB MEMORY USED (113) 

@KB DISK SPACE USED 


END OF PL/M-286 COMPILATION 
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System-ID PL/M-286 Vx.y COMPILATION OF MODULE BOND 
OBJECT MODULE PLACED IN :F1:BOND. OBJ 
COMPILER INVOKED BY: PLM286.86 :F1:BOND. PLM DEBUG 


S$ PAGEWIDTH(71) TITLE('96@0-521') 
$ INCLUDE (:F1:NUCSUB.PLM) — 

= S NOLIST 
$ INCLUDE (:F1l:UDISUB. PLM) 
$ 
$ 


= NOLIST 
COMPACT 
1 BOND: DO; 
[ROUSSE O ITI IIIS III III IOUS III III III TAI TISAI] 
/* | | Language Extensions a7 
2 1 DECLARE BOOLEAN LITERALLY 'BYTE', 
FALSE | LITERALLY '@',. 
TRUE LITERALLY '@FFH', 
TOKEN _ LITERALLY 'WORD', 
CONNECTION LITERALLY 'TOKEN', 
OFFSET LITERALLY "WORD'; 
[OGIO OIC ISI IICIOII ICICI IOI IIIT IIIT IIIT TOTTI K / 
f* Externals | “7 
3 #1 RESERVE SLOTS: PROCEDURE (TABLE, COUNT, SLOT. PTR,EXCEP_PTR) 
EXTERNAL; 
4 2 DECLARE TABLE WORD, COUNT WORD, (SLOT PTR, EXCEP_ PTR) 
POINTER; 
5 2 END RESERVE SLOTS; 
6 1 GET GATE POINTER: PROCEDURE (GATE SEL, SEG SEL PTR, 


SEG _OFFSET _PTR, EXCEP_PTR) EXTERNAL; 
/* Returns selector and offset from a gate PESCEAREOE */: 


7 2 DECLARE GATE SEL SELECTOR, 
(SEG SEL _PTR, SEG _OFFSET as EXCEP PTR) POINTER; 
8 2 END GET _GATE _POINTER; 
9 1 ALLOCATE: PROCEDURE (SLOT, RIGHTS, SIZE, EXCEP PTR) 
EXTERNAL; 
19 2 DECLARE SLOT SELECTOR, RIGHTS BYTE, SIZE WORD, 
EXCEP PTR POINTER; . 
1l 2 END ALLOCATE; 
12 1 REPORT: PROCEDURE (EXCEP_PTR) EXTERNAL; 
£3 2 DECLARE EXCEP PTR POINTER; 
14 2 END REPORT; 
15 1 DQSATTACH: 
PROCEDURE (PATHSP, EXCEPSP) CONNECTION EXTERNAL; 
16 2 DECLARE (PATHSP, EXCEPSP) POINTER; 
17 2 END DQSATTACH; 


18 2 DQSDETACHs PROCEDURE (CONN, EXCEPSP) EXTERNAL; 
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19 2 DECLARE CONN CONNECTION, EXCEPSP POINTER; 
20 2 END DQSDETACH; 
21 HF DQSOPEN: | 
PROCEDURE (CONN, ACCESS, NUMSBUF, EXCEPSP) EXTERNAL; 
22 2 DECLARE CONN CONNECTION, (ACCESS, NUMSBUF) BYTE, 
EXCEPSP POINTER; 
23 2 END DQSOPEN; 
24 1 DQOSSEEK: PROCEDURE 
(CONN, MODE, LOCATION, EXCEPSP) EXTERNAL; 
25 2 DECLARE CONN CONNECTION, MODE BYTE, 
LOCATION DWORD, EXCEPSP POINTER; 
26 2 END DQSSEEK; . 
27 af DQOSREAD: PROCEDURE 
(CONN, BUFSP, COUNT, EXCEPSP) WORD EXTERNAL; 
28 2 DECLARE CONN CONNECTION, COUNT WORD, ~ 
(BUFSP, EXCEPSP) POINTER; 
29 2 END DQSREAD; 
30 1 DQSCLOSE:: PROCEDURE (CONN, EXCEPSP) EXTERNAL; 
31 2 DECLARE CONN Cl ecree EXCEPSP POINTER; 
32 «2 END DQSCLOSE; | 3 | 
[BKK HIKER ERK KKK RR RHR RE RRR EKER EERE KEKE EEK ERE EKER / 
/* . Data */ 
33 1 DECLARE IN LDT LITERALLY a sa 
DATA_W LITERALLY '11110016B', /* Access rights: 
present, DPL=3, expand-up, writable, data Segment */ 
READ LITERALLY ‘'l', : 
EQUALS LITERALLY ‘OFFFFH', 
OK LITERALLY ‘@', 
EXCEPTION LITERALLY 'BXCEP<>OK': 
34 1 DECLARE BOND FILE CONNECTION, 
ACTUAL WORD, 
SEL : SELECTOR, /* for type conversion */ 
~ WSEL WORD AT AES ELI 
35 1 DECLARE FILE HEADER BYTE; 
36 1 DECLARE MODULE HEADER . STRUCTURE ( 
; TOTAL LENGTH DWORD, 
SEGMENT COUNT: WORD, 
GATE_COUNT WORD, 
PUB COUNT . WORD, 
EXT COUNT | WORD, 
LINKED BYTE, 
DATE (8) BYTE, 
TIME (8) BYTE, 
MODULE NAME (41) BYTE, 
CREATOR (41) BYTE, 
IGNORE] © ; (6) DWORD, 
PUBDEF_LOC 7 DWORD, 
PUBDEF LENGTH DWORD, 
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37 


38 


63 


64 


NNN 


-IGNORE2 (8) DWORD) ; 


/* Table of actual locations of 0.S. primitives */ 
DECLARE BOND SEL SELECTOR, 
BOND BASED BOND SEL (2) STRUCTURE ( 
GATE _NAME (41) BYTE, 
ENTRY POINT OFFSET, 


GDT_ SEL SELECTOR 1% 
BIX WORD; /* Index */ 
DECLARE PUBDEF: STRUCTURE 

(ENTRY POINT WORD, 

GDT_IN WORD, 

IGNORE WORD, 

WORD_COUNT BYTE, 

LENGTH . BYTE); 


3 


AO IGO SISO I IOS USIISU EI ISOC UI IIS ISO III ISO I II IIT IO / 


/* se - Subroutines 


/* Create table of actual GDT selectors and 
entry points for 0.S. primitives. */ 


BUILD BOND TABLE: PROCEDURE (BOND NAME PTR, EXCEP_ PTR) 
PUBLIC; 
DECLARE (BOND NAME PTR, EXCEP PTR) POINTER; 
DECLARE EXCEP BASED EXCEP PTR WORD; 


/* Initialize file */ 
BOND_FILE= DQOSATTACH (BOND_ NAME J PIRY @EXCEP); 

IF EXCEPTION THEN RETURN; 
CALL DQSOPEN (BOND FILE, READ, ig @EXCEP); 

IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 

/* Read file header */ 
ACTUAL=DQSREAD (BOND FILE,@FILE_HEADER,1,@EXCEP); 
IF EXCEPTION THEN CALL REPORT (@EXCEP); 

/* Read module header */ 
ACTUAL=DQSREAD (BOND FILE,@MODULE HEADER, 

SIZE(MODULE HEADER), @EXCEP); 

IF EXCEPTION THEN CALL REPORT (@EXCEP); 

/* Get space for table */ 
CALL RESERVE SLOTS (IN | LDT,1,@BOND SEL,@EXCEP); 
IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 
CALL ALLOCATE (BOND SEL, DATA_W, 

(MODULE HEADER. PUB “COUNT+1) *SIZE (BOND (@)) @EXCEP); 

IF EXCEPTION THEN CALL REPORT (@EXCEP) ; 


/* Read the PUBDEF section */ 
/* (Locations are relative to beginning of module, 
not beginning of file. Assume module atl.) */ 
CALL DQSSEEK (BOND FILE,2,MODULE_HEADER.PUBDEF_LOC+1, 
@EXCEP) ; 

IF EXCEPTION THEN CALL REPORT (@EXCEP); 

/* Loop thru the PUBDEF entries */ 
DO BIX = @ TO MODULE HEADER.PUB COUNT-1; 

/* Read fixed part of PUBDEF record «/ 
ACTUAL=DQSREAD (BOND FILE, @PUBDEF, 8, @EXCEP); 
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65 3 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
/* Convert index into GDT selector */ 
67 3 WSEL=SHL(PUBDEF.GDT IN,3);} 
/* Extract gate selector and offset from GDT */ 
68 3 CALL GET _GATE _POINTER (SEL, @BOND(BIX) .GDT _SEL, 
@BOND(BIX). ENTRY _ POINT, @EXCEP); 
69 3 IF EXCEPTION THEN CALL REPORT ty aaa 
/* Read variable-length name */ 
71 3 BOND(BIX). GATE _NAME (@)= PUBDEF. LENGTH; ; 
72 3 ACT AL=DQSREAD (BOND_FILE,@BOND(BIX) .GATE_NAME(1), 
PUBDEF. LENGTH, @EXCEP) ; 
73 3 IF EXCEPTION THEN CALL REPORT (@EXCEP); 
75 3 END /* looping thru PUBDEF entries */; 
76 «2 END BUILD BOND TABLE; 


[BRR RRR KKK IKKE HIKE KKK KEKE KKK IKK EKER KEKE EKER KEE KK / 


77 1 FIND BOND: PROCEDURE (SNAME PTR, ENTRY PTR, SEL PTR, 
EXCEP PTR) PUBLIC; 


/* Search BOND table for given name. 


Return items from found entry. *7 
78 2 DECLARE (SNAME PTR, ENTRY _ PTR, SEL PTR, EXCEP_ PTR) 
POINTER; ) So 

79 2 . DECLARE SNAME | BASED SNAME_ PTR (41) BYTE, 

ENTRY POINT BASED ENTRY: PTR WORD, 

GDT_SEL BASED SEL_PTR SELECTOR, 

EXCEP BASED EXCEP_ PTR WORD; 
80 2 DO BIX = @ TO MODULE _HEADER.PUB_COUNT-1; 
81 3 IF SNAME(@)=BOND(BIX) .GATE _NAME (@) /* Same length? */ 

THEN /* Compare characters */ 
82 3 IF EQUALS=CMPB(@SNAME (1), @BOND(BIX). GATE _NAME(1), 
SNAME (@) ) 
83 3 THEN DO; 
84 4 ENTRY POINT=BOND(BIX). ENTRY POINT; 
85 4 GDT _SEL= BOND (BIX) .GDT_SEL; 
86 4 EXCEP= OK; 
87 4 RETURN; 
88 4 END; 
89 3 END; 
98 2 EXCEP=NOT OK; 
91 2 RETURN; 
92 2 END FIND BOND; 
[BRR RRR KKRKRKRERKKEKKEKREREKRKEKKKKKKRA KKK KAKA KAR / 

93 EA END BOND; 


MODULE INFORMATION: 


Figure 11-7. BOND Module of Binding Loader (Cont’d.) 
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PL/M-286 COMPILER 960-521 


@2CBH 
O000H 
68C2H 
@@1CH 


CODE AREA SIZE 
CONSTANT AREA: SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
245 LINES READ 

@ PROGRAM WARNINGS) 
@ PROGRAM ERRORS 


DICTIONARY SUMMARY: 


96KB MEMORY AVAILABLE 
8KB MEMORY USED (8%) 
@KB DISK SPACE USED 


END OF PL/M-286 COMPILATION 


Figure 11-7. BOND Module of Binding Loader (Cont’d.) 
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CHAPTER 12 
NUMERICS PROCESSOR EXTENSION 


The iAPX 286/20 is a configuration of chips consisting of an 80286 CPU and an 80287 Numerics 
Processor Extension (NPX). With these two cooperating processors it is possible to construct powerful 
numerics processing systems, but the operating system must multiplex the 80287 among the tasks that 
use it. If the system does not include an 80287, you may choose to have the operating system emulate 
its functions. 


iAPX 286/20 NUMERICS PROCESSING FEATURES 


Several features of the iAPX 286/20 are of special interest to operating- system designers and program- 
mers. You can find more details on how to use the iAPX 286/20 in the iAPX 286 Programmer's 
Reference Manual. 


ESCAPE Instructions 


The 80287 NPX extends the instruction set of the iAPX 286 by over fifty opcodes. The CPU identifies 
the extended instruction set by the bit pattern 11011B in the high-order five bits of the first byte of 
the instruction. Instructions thus marked are called ESCAPE or ESC instructions. 


The CPU performs some functions upon encountering an ESC instruction, before sending the instruc- 
tion to the NPX. Those functions that are of interest to the operating system include 


¢ Testing the emulation mode (EM) flag to determine whether NPX functions are being emulated by 
software. | 


e Testing the TS flag to determine whether there has been a context change since the last ESC 
Instruction. | 


e For some ESC instructions, testing the ERROR pin to determine whether an error ponditien exists 
at the NPX as a result of a previous ESC instruction. 


The ASM286 Assembly Language Reference Manual provides more information on ai 80287 
instruction. 


Emulation Mode Flag (EM) 


The EM bit of the 80286 machine status word (MSW) indicates to the CPU whether NPX functions 
are to be emulated. If the processor finds EM set when executing an ESC instruction, it causes trap 7, 
giving the exception handler an opportunity to emulate the functions of an 80287. The EM flag can be 
changed with the aid of LMSW (load machine status word) instruction (legal only at privilege level 0 
(PL 0)) and tested with the aid of the SMSW (store machine status word). The built-in variable 
MACHINESSTATUS gives PL/M-286 programs access to the MSW. 


The EM bit also controls the function of the WAIT instruction. If the processor finds EM set while 
executing a WAIT, the processor does not check the ERROR pin for an error indication. 


Note that EM must never be set concurrently with MP. 
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Math Present Flag (MP) 


The MP bit of the 80286 auchite status word (MSW) anticnteet to the CPU whether an 80287 NPX 
is actually attached. The MP flag controls the function of the WAIT instruction. If, when executing a 
WAIT instruction, the CPU finds MP set, then it tests TS; it does not otherwise test TS cunne 2 a 
WAIT instruction. If it ne TS set under these conditions, the CPU causes trap oC 


Note that MP must never be set concurrently with EM. 


Task Switched Flag (TS) 


The TS bit of the MSW helps to determine when the context of the 80287 NPX does not match that 
of the 80286 CPU. The CPU sets TS each time it performs a task switch (whether triggered by software 
or by hardware interrupt). If, when interpreting one of the ESC instructions, the CPU finds TS already 
set, it causes trap 7. The MP flag also relates to TS. 


The CLTS instruction (legal only at PL 0) resets TS. 


WAIT Instruction 


The WAIT instruction is not an ESC instruction, but WAIT causes the CPU to perform some of the 
same tests that it performs upon encountering an ESC instruction: 


¢ The CPU waits until the NPX no longer asserts the BUSY pin. You can therefore use WAIT to 


synchronize the CPU with the NPX. 


e The CPU tests the ERROR pin (if EM is not set). You can therefore use WAIT to cause trap 16 
if an error is pending from a previous ESC instruction. (The CPU makes this test only after BUSY 
goes inactive.) Note that, if no 80287 is present, the ERROR pin should be tied inactive to prevent 
WAIT from causing spurious aa, 


Summary 

Table 12-1 summarizes functions of the ESC and WAIT instructions that depend on setting of the MP 
and EM flags. 

INITIALIZATION 

PUES its ee pues’ the SOPHIE system must — 


° Set flags j in the MSW to reflect the numerics processing environment 

° Reset the 80287 (if present) 

¢ Switch the 80287 into protected mode 

You can use a configuration parameter to communicate the numerics processing environment to the 


operating system. The FNINIT instruction INITSREALSMATH$UNIT in PL/M-286) resets the 
80287, and the FSETPM instruction places the 80287 into protected mode. 
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Table 12-1. Interpretation of MP and EM Flags 


“TRAP 7? 
TEST BUSY? 


TEST ERROR? 
(TRAP 16) 


TRAP 7? 
TEST BUSY? 


TEST ERROR? 
(TRAP 16) 


ESCAPE 


TASK STATE 


When a task uses the 80287 NPX, the operating system has two additional concerns in keeping track 
of the task’s state: 


e The task database must be expanded to sciude 47 words of state information for the 80287. 


e The operating system must change 80287 state when a different task attempts to use the 80287. 


The state of the 80287 ponsists of 47 Weide aviie and restoring the 80287 state is therefore a gelatively 
expensive operation that should not be performed any more frequently than necessary. Typically, only 
a few of the active tasks in a system use the NPX; therefore, it would be wasteful to save and update 
the state information with every task switch. It is preferable for the operating system to record which 
task is using the 80287 and to swap state information only when some other task attempts to use the 
80287. | _ 


The 80286 supports sharing of the 80287 by providing the TS flag. The processor automatically sets 
the TS every time a task switch occurs. The first use of an ESC or WAIT instruction when the TS is 


set causes trap 7. This enables the operating system to keep track of the task to which the NPX is 
assigned at any given time and to change 80287 state when necessary. no 


NUMERICS EXCEPTIONS | 

Three interrupt vector positions are reserved for excepuane that relate to numerics processing. Inter- 
rupts for these vectors are not maskable. : 

Interrupt 7—Processor Extension Not Available (NM) 

This exception occurs in either of two CongiHlonsy: 


¢ The CPU encounters an ESC instruction and EM is set. In this case, the exception handler should 
emulate the instruction that caused the exception. TS may also be set. 
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e The CPU encounters either the WAIT instruction or an ESC instruction when both MP and TS are 
set. In this case, the exception handler should update the state of the NPX if necessary. 


EMULATION 


The return link points to the first byte of the ESC instruction (or to the prefix byte, if any). As the 
emulator decodes the ESC instruction, it should step the return pointer so that, at the end of the 
emulation routine, the return from the exception handler causes execution to resume at the first 
instruction following the ESC instruction. 


UPDATING STATE 


To make sure that ‘hee state of the NPX corresponds to the current task, the operating system should 
implement the concept of “ownership” of the NPX. Ownership can be indicated by a Boolean in the 
task database (TDB). The operating system must ensure that only one task at a time is marked as the 
owner of the NPX. The exception handler should follow these steps: 


1. Use the CLTS instruction to reset TS. 
2. Return if the current task owns the NPX. 


3. Use the FSAVE ESC instruction (PL/M-286 nero ear ag to store NPX context in 
the former owner’s task database. 


4. Record the current task as the owner of the NPX. 


5. Use the FRSTOR ESC instruction (PL/M-286 RESTORE$REALS$STATUS) to load the NPX 
context from the new owner’s TDB. 


Since task switches may occur during execution of the exception handler, steps 3, 4, and 5 are a critical 
region and must be protected by a mechanism such as a semaphore. 


The exception handler must run at PL 0, both pecans it alters the critical task ashes at PL 0 and 
pecduse it uses the privileged instruction CLTS. 


The exception handler must be an interrupt procedure, not an interrupt task. If it were an interrupt 
task, the task switch that occurs upon cue from the exception handler would set TS, Enerey 
causing the exception again. 


The return link points to the first byte of the interrupted instruction. Return from the re handler 
causes restart of that instruction, but this time TS is reset and the instruction can proceed. 


Interrupt 9—Processor Extension Segment Overrun (MP) 


This exception occurs when a memory operand of an 80287 instruction has a segment-limit violation. 
Since the 80287 executes in parallel with the 80286, two difficulties may arise: 


e The occurrence of this exception may not relate directly to the instruction stream being executed 
by the current task. A task switch may have occurred since the 80287 began executing the instruc- 
tion. Even if the interrupted task is the correct task, its IP may have been advanced by several 
instructions beyond the ESC instruction. 


e Since the exception is not maskable, it may occur while interrupts are disabled. If minimum inter- 
rupt latency is important, the exception handler must do as little as possible. It could, for example, 
record the error for later handling. . 
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The offending ESC instruction cannot be restarted. The task containing the ESC instruction (which 
may not be the current task) must eventually be cancelled. 


The exception handler must execute an FINIT instruction before executing a WAIT or other ESC 
instruction; otherwise, the WAIT or ESC instruction will never finish. FINIT does not affect the CS:IP 
value and data address saved in the 80287. 


Note that the 80286 CPU detects some addressing violations before sending the ESC instruction to 
the 80287 NPX. In these cases, the CPU causes trap 13 (pushing an error code of zero), and it is 
generally possible to restart the ESC instruction. Refer to Chapter 7 for more information regarding 
trap 13. 


Interrupt 16—Processor Extension Error (MF) 


The 80287 detects six different exception conditions during instruction execution. If the detected 
exception is not masked by a bit in the control word, the 80287 communicates the fact that an error 
occurred to the CPU by a signal at the ERROR pin. The CPU causes interrupt 16 the next time it 
checks the ERROR pin, which is only at the beginning of a subsequent WAIT or certain ESC instruc- 
tions. If the exception is masked, the 80287 handles the exception according to on-board logic; it does 
not assert the ERROR pin in this case. 


The six exception conditions are 


1. INVALID OPERATION 

2. OVERFLOW 

3. ZERO DIVISOR 

4. UNDERFLOW 

5. DENORMALIZED OPERAND 

6. PRECISION (INEXACT RESULT) 


The steps to be taken to remove the error condition depend on the application. 


Once the exception handler corrects the error condition causing the exception, the floating point 
instruction that caused the exception can be restarted, if appropriate. This cannot be accomplished by 
IRET, however, because the trap occurs at the ESC or WAIT instruction following the offending ESC 
instruction. The handler must obtain from the 80287 the address of the offending instruction in the 
task that initiated it, make a copy of it, execute the copy in the context of the offending task, and then 
return via IRET to the current CPU instruction stream. 


The ESC instructions that do not cause automatic checking of the ERROR pin are FNCLEX, FNINIT, 


FSAVE, FSETPM, FSTCW, FSTENYV, and FSTSW. You can use the WAIT instruction to test the 
ERROR pin before these instructions, if necessary. 
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Extended Protection 


13 


CHAPTER 13 
EXTENDED PROTECTION 


Even though the iAPX 286 architecture provides extensive, automatic protection, a fully protected 
system requires additional protection features in the operating system. Operating-system software can 
increase the reliability of the system by providing any of these protection features: 

e Extending the “type” concept 

e Validating pointer parameters 

¢ Defining the right to use operating-system objects 

¢ Defining the right to delete segments 


¢ Protecting shared objects that are being constructed 


EXTENDED TYPE 


It is both convenient and dangerous to use a selector as the name of an operating-system object. The 
danger arises from the fact that the selector by itself carries no information regarding the type of object 
it identifies. A program can, for example, mistakenly pass the selector of a semaphore to an operating- 
system procedure that operates on mailboxes, producing catastrophic results. The solution is to associ- 
ate a type extension code for the object with the segment in which it resides or with a descriptor to 
that segment. Operating-system procedures can then check the type of objects identified by selector 
parameters. (The term type extension code is used here to avoid confusion with the processor-recognized 
type code in a descriptor.) 


There are three general methods of associating type with operating-system objects: 


1. Place the type extension code in the segment in which the object resides. 
2. Associate the type code with a descriptor for the segment. | 


3. Use indirect names and associate the type code with the name of the object. 


Only segments likely to contain named operating-system objects need to have type extension codes; 
namely, privilege-level 0 (PL 0), expand up, writable, data segments. 


Type Extension Code with Descriptor 


A logical way to store a type extension code is to associate it with the descriptor for the named object 
(you can view the type extension code as a refinement of the processor-recognized type code in the 
access-rights byte of the descriptor). The type extension code can be put in a table parallel to the 
descriptor table (as illustrated in Chapter 5 in connection with alias-list pointers). 


Type Extension Code in Segment 


It is also possible to place the type extension code at some reserved location in the data segment itself. 
This approach does not reference another segment and thereby avoids loading a segment register. 
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Indirect Naming 


The most general approach to naming avoids giving to less privileged procedures any direct links to 
the named objects. Instead, names are indexes (or perhaps pointers) into a name table, which is admin- 
istered by the operating system at a highly privileged level. Each entry in the name table holds the 
type extension code of the object, the selector of the segment in which the object resides, and any other 
information needed to ensure appropriate use of the object. This approach not only offers the greatest 
potential for protection, but also makes it possible to change the naming scheme without affecting 
procedures that use the names and provides a consistent way of naming both those objects that reside 
in dedicated segments and those that are packed into a segment with other objects. 


PARAMETER VALIDATION 


There is one type of privilege violation that the iAPX 286 cannot automatically check for. Consider, 
for example, procedure A at PL 3 that passes a pointer parameter via the stack to procedure B at 
PL 1. Procedure A could (accidently or purposely) pass a pointer that refers to a data structure at 
PL 2. Doing so would violate the intent of the protection features of the iAPX 286 because procedure 
A does not have sufficient privilege to operate on the data structure. However, the processor does not 
detect the violation because procedure B, which actually addresses the data structure, does have suffi- 
cient privilege to do so. 


The iAPX 286 provides the RPL field in the selector as well as the instructions shown i in table 13- 1 to 
help software guard against such protection violations. 


In addition to type checking as mentioned previously, an operating system can provide two levels of 
parameter validation: | | 


1. Defensive use of ARPL instruction 


2.  Point-of-entry scrutiny 


Defensive Use of ARPL 


Simply by applying the ARPL instruction to every pointer parameter it receives, an operating system. 
procedure guards against complicity in accessing a segment that the calling procedure has no right to 
access. ARPL has two selector operands, for example: 


ARPL sel_a, sel_b 


Table 13-1. Access Checking Instructions | 


- ASM286 | PL/M-286 Built-In F Description 
Mnemonic Function | | ae 


ADJUST$RPL | Adjust requested privilege level 


SEGMENT$READABLE Verify segment for reading 
SEGMENT$WRITABLE Verify segment for writing 
GET$ACCESS$RIGHTS Load access rights 
GET$SEGMENTS$LIMIT Load segment limit 
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ARPL adjusts the RPL field of se/_a to the greater of its current value and the value of the RPL field 
in sel_b. | 7 _ : : ve | 


The CPL of the calling procedure is stored in the RPL field of the return pointer on the stack, as figure 
13-1 illustrates. Assuming the parameter is also on the stack, statements of the form 


MOV AX, STACK_FRAME.RETURN_SEL 
ARPL STACK_FRAME.PARAM_SEL, AX 


can be used to ensure that the RPL field of the parameter is not less that the calling procedure’s CPL. 
When the called procedure uses the parameter, the processor evaluates its right to use the parameter 
as if it had the privilege level of the calling procedure. If the calling procedure passes a parameter that 
it has no right to use, an exception will occur when the called procedure uses the parameter. 


Every operating system procedure should apply the ARPL instruction to every pointer or selector 
parameter it receives, even if the calling procedure is another operating-system procedure. This provides 
inexpensive protection against accidental use of invalid parameters. 


Point-of-Entry Scrutiny 


While use of ARPL alone is sufficient to detect such invalid parameters, it has one drawback: it does 
not help to isolate the source of the invalid parameter. An exception will eventually occur when some 
higher-level procedure uses the parameter, but this may not happen until several instructions after the 
procedure was called, and may not happen until after the called procedure passes the parameter to yet 


DIRECTION 
OF GROWTH 
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Figure 13-1. Caller’s CPL 
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another pisecdute. To detect parameter errors at the earliest opportunity, the operating system snows 
examine pointer parameters with the VERR, VERW, LAR, and LSL instructions. 


The strategy for scrutinizing a pointer parameter includes 


* Using ARPL as described previously to ensure that the RPL field of the pointer parameter contains 
the calling procedure’s privilege level. 


e Using VERR or VERW to ensure that the iadionied segment is décemible at the calling Bieedure: S 
privilege level. VERR also determines whether the indicated segment is readable; an execute-only 
segment, for example, is not readable. VERW also determines whether the segment is writable; 
only a writable data segment passes this test. 


° Using LAR and LSL to make sure that the offset portion of the pointer parameter actually points 
to a location within the boundaries of the segment. LAR makes the access-rights byte of the indicated 
descriptor available, so you can determine whether the segment is an expand-down data segment. 
LSL makes the segment-limit field of the descriptor available. If the segment is an expand-down 
‘data segment, the offset portion of the pointer parameter must be greater than or equal to the 
segment limit; otherwise the offset must be strictly less than the limit. 


Refer to the appropriate language reference manual for details concerning the use of these instructions. 


This strategy for parameter validation is somewhat more costly than using the ARPL instruction alone, 
as described in the previous section. Therefore, you may wish to limit use of this strategy to those 
operating system procedures that can be called by less privileged, applications procedures. 


USAGE PRIVILEGE LEVEL 


Generally, operating system primitives that act on operating system objects (such as the semaphores 
and mailboxes discussed in Chapter 5) have call gates at PL 3. Without further protection, procedures 
at any privilege level in a task can use those objects for which descriptors exist in the LDT. Such 
freedom violates the principle behind privilege levels, however. Consider these two cases: 


e A database-management system that runs at PL 2 creates a mailbox for passing recovery informa- 
tion to a separate task that is responsible for writing recovery information to a magnetic tape. A 
task at PL 3 accidently uses the wrong selector in a call to the operating system and sends an 

unrelated message to that mailbox. Later, when using the audit tape to reconstuct the database, the 
database system reads the strange record and fails. 


¢ Procedures of the same database system use a shared data segment so that they can access common 
database parameters regardless of what task they run in. To synchronize their access to the common 
data, they define and use a semaphore. A less privileged task uses a wrong selector in a call to the 
operating system and signals this semaphore prematurely, permitting the shared data to be incor- 
rectly changed. The database system fails when it next tries to use the incorrect data. 


These examples illustrate the need for additional protection over the use of operating-system objects, 
‘such as semaphores and mailboxes. 


By associating a usage privilege level (UPL) with objects, the operating system can provide protection 
analogous to that provided by hardware for access to segments. By means of a privilege-level parameter 
to the creation procedure, the task that creates an object defines the maximum (numerical) privilege 
level that can use the object. The UPL can be stored either in the data structures that define the object 
or (if indirect naming is used) with the name of the object. In the procedures that operate on the object, 
the operating system can check whether the calling procedure’s privilege level exceeds the UPL of the 
object. The calling procedure’s privilege level is readily available on the stack, as figure 13-1 illustrates. 
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SEND PRIVILEGE LEVEL 


Moving or deleting the descriptor for a segment or the name of an object may have even more drastic 
effects on other tasks than using the code or structures in the segment or object. Consider the effect of 
deleting or mailing away a descriptor for a global data segment (for example, a translation table) 
shared by all tasks in the system. A task that assumes the existence of the global segment will cause 
an exception when it references the deleted descriptor slot. This points out the need for control over 
the right to send or delete a descriptor. 


One way of implementing such control is to associate with each descriptor (including alias descriptors) 
a send privilege level (SPL). Procedures that move or delete descriptors (such as SEND_.MESSAGE 
and DELETE_ALIAS) interpret the SPL and ensure that the calling procedure cannot delete (send) 
a descriptor from the GDT or its LDT unless CPL <= SPL. SPL for segments is an attribute of 
segment descriptors and can be stored in tables parallel to descriptor tables. 


The SPL and UPL for operating system objects may be different. In general, the SPL of all descriptors 

in the GDT should be zero or one, limiting the deletion and movement of GDT descriptors to the most 
privileged levels of the operating system. It is quite reasonable, however, to have GDT-based objects 
with UPL of three, so that they are accessible from any level. 


CONSTRUCTING SHARED OBJECTS 


Since the procedure that builds a GDT-based object, such as a mailbox or semaphore, must have a 
descriptor for the object’s data segment, there is a possibility (however slight) that some other task (for 
example, an interrupt task) might mistakenly use a selector for the object under construction in a 
request to the operating system to use a similar object. The results are unpredictable, but probably 
disastrous. There are several possible methods for guarding against such a circumstance: 


e Lock out all other activity for that type of object by using a semaphore or other synchronization 
primitive. 

e For the purposes of construction only, use a reserved descriptor slot that other operating-system 
procedures recognize as invalid. 

e For the purposes of construction only, use an LDT slot of the task that is building the object. 


¢ Use an invalid type extension code for the object until it is completely built. 
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8254 Programmable Interval Timer: an Intel counter/timer device that provides three independent 
16-bit counters and six counter modes. For operating- si appieavou the 8254 can provide timed 
interrupts for use by the software scheduler. : . 
8259A Programmable Interrupt Controller: an Intel device that handles up to Pen vectored priority 
interrupts for the CPU. The chip is designed to minimize software and real-time overhead in handling 
multi-level priority interrupts. It has several software selectable modes, permitting Spumizanott for a 
variety of system requirements. | 

80286: the CPU chip of élie iAPX 286 architecture. 

80287: the numerics processor extension chip of the iAPX 286/20 chip set. 


access rights: the attributes of a segment, defined by a descriptor, that control how a segment can be 
used by instructions in other segments. | a 


accessed bit: a Boolean in the access rights byte of a descriptor that the processor sets when it loads 
the descriptor into a segment register. _ 


address mapper: a hardware device that selectively translates the CPU’s addressing signals into signals 
of ene oe sh 


alias one af several descriptors for a segment. Each alias may define a different type, access rights, 
or (in some cases) limit for the segment. 


alias list: a data structure that enables the operating system to find all the aliases for a given segment. 
asynchronous: characterized by unpredictable order in the occurrence of events; not synchronous. 
back link: the selector field in a TSS that identifies the task to be invoked when the current task 
executes an IRET instruction. The processor reads the back link only if the NT flag is set. The proces- 
sor sets the back link to mE POnk to hs TSS of the former task when a CALL instruction or eee 
causes a task switch. ; : ee 


base address: the 24-bit address in physical memory at which a segment starts. 


busy task: either the currently executing task or a task on a back-link chain from the currently execut- 
ing task. A busy task has a type code of three in the descriptor for its TSS. 


Binder: see iAPX 286 Binder. 


binding: the process of translating a symone reference to a form that the processor can interpret 
directly. a ee 


bootloader: sec bootstrap loader. 
bootstrap loader: a small, usually ROM- resident, program whose eureeons is to load a larger, oe 


featured loader. 
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bootloadable module: a module containing absolute object code in a simple format that expedites loading 
by a bootstrap loader. 


boundary tag: a field at the low or high end of a block of memory used by the memory allocation 
algorithm to distinguish between allocated and unallocated blocks. | 


beediipoint a position in a program marred’ in such a way that intervention can occur when execution 
_ of the program reaches that position. 


buddy system: a memory-management algorithm that partitions memory into pairs of memory blocks 
of equal size. When both blocks of a pair are not used, they are combined into a larger block that also 
has a partner or “buddy” of the larger size. 

buffer: an area of RAM used for transferring data to or from an external device. 

built-in: in PL/M-286, a predefined identifier. 

Builder: see iAPX 286 System Builder. 


BUSY: an input pin to the 80286 used by a processor extension such as the 80287 to indicate when 
the processor extension is unable to accept a new instruction. 


call gate: a gate used to transfer control to a procedure in a segment of the same task at an equal or 
(numerically) lesser privilege level. 


carry flag (CF): one of the six arithmetic flags typically used for unsigned integer comparisons and 
extended precision arithmetic. Se is set oy a carry into, or a borrow from, the high-order bit of a result 
operand. | 


code segment: see executable segment. 


combine type: one of the chamecionetics that the Binder associates with scements: The Binder FOMIUINES 
segments only if they have compatible combine types. , | 


compaction: relocating allocated memory segments into consecutive locations in order to bring together 
all unallocated memory blocks. . . 


spiupilet Sontro} statement: source statements that specify options to the compiler. Control statements 
begin with a dollar sign ($) in the left margin. 


conforming segment: an executable segment that executes at the CPL of any segment that calls it. A 
conforming segment is identified by a bit in the access rights byte of its descriptor. 


control flow transfer: any change. in the normal sequential progress of a program. JMP, CALL, RET, 
IRET, and INT instructions, as well as exceptions and external interrupts, can cause a change in 
control flow. 


coroutine: a type of subroutine that cooperates with other coroutines in quasi-parallel execution. A set 
of related coroutines transfer control from one to another. Each coroutine maintains local variables 
across invocations and maintains an independent instruction counter that determines where to begin 
execution upon next invocation. 


critical section: a procedure or portion of a procedure that operates on shared data in such a way that 
it may act incorrectly if another procedure operates on the same data within the same time interval. 
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CS (code segment) register: the segment register that provides addressability for access to instructions. 
current privilege level (CPL): the privilege level that the processor is using to execute the currently- 
accessible executable segment. CPL may be equal to DPL of the executable segment, or CPL may be 


numerically greater that DPL if the segment is conforming. 


data segment: a segment that contains data (other than immediate data) for an executable segment. 
A data segment is identified by a specific type code in the descriptor of the segment. 


asic dai an eight-byte item that defines the use of memory in an iAPX 286 protected-mode system. 


oe ee table: one of the processor-recognized tables that contain the descriptors for the system, 
These tables are the GDT, the IDT, and LDTs. 


Ree privilege level (DPL): the privilege level defined in the descriptor of a segment. 


device driver: the task or procedures that use Prowiedee of the physical characteristics of an I/O 
device to carry out higher-level I/O requests. _ 


direct I/O: I/O Opetaucus in which the CPU pesceipats 


dispatching: determining which task the processor suid work on, and switching the processor to that 
task; also erown as “scheduling.” 


double fault: a fault that occurs while the processor is attempting to handle a prior fault. 
DS (data segment) register: one of three segment registers that provide addressability to data segments. 
dynamic system: an application in which tasks begin and end relatively frequently. 


EM (emulation mode) bit: a Boolean in the MSW that indicates to the processor whether ESC instruc- 
tion processing is being emulated by software. 


emulation: software interpretation of instructions for a processing device (such as the 80287 Numerics 
Processor Extension) that is not present in the system. 


entry point: an executable-segment offset that identifies the starting point for execution, as when the 
segment is invoked via a gate. | 


error code: a word automatically pushed on the stack as a result of certain exceptions. The error code 
helps identify the segment involved in the exception. 


ERROR: an input pin of the 80286 used by a processor extension (such as the 80287) to signal error 
conditions. 


ES (extra sepment) register: onc of three segment registers that provide ey to data segments. 


ESC or ESCAPE instruction: an instruction (usually for a processor extension) identified by the five- 
bit prefix 11011B. “g 


EX (external) bit: a Boolean in the error code which, when set, indicates that the exception is due to 
factors outside the control of the task in which the exception occurs. 
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exception: a processor-detected condition that requires software intervention. The iAPX 286 commu- 
nicates exceptions to software by means of the ne mechanism. 


sieoutabie segment: a segment that contains processor instructions. An executable segment is identi- 
fied by a specific type code in its descriptor. 


execute-only segment: a special case of an executable segment that the processor can access for the 
purpose of fetching instructions but cannot access for the purposes of reading data. An execute-only 
segment is identified by a Boolean in the access-rights byte of its descriptor. 


expand-down segment: a data segment that contains a data structure (such as a stack) that grows 
toward lower memory locations..An expand-down segment is identified by a Boolean in the access- 
rights byte of its descriptor. Offset addresses in an expand-down segment extend from the value contained 
in the limit field of the descriptor thru OFFFFH. 

exportation: a process by which a system-software interface is made available to applications and other 
system programs. Gates and segments providing access to system services (such as operating-system 
primitives) are placed, via the Builder’s export definition, into a linkable module. This module is used 
when building loadable tasks that depend on the exported Services: 


EXPORTS list: a clause of PL/M-286’s extended segmentation control syntax that specifies the sdbiis 
identifiers that may be referenced from outside a subsystem. 


external reference: a reference to an identifier that is defined as PUBLIC in another module. 
fault: an UAE that results from an exception. 


fetch policy: the algorithm that determines which segment to bring into RAM from secondary re 
and when to bring it in. , 


first fit algorithm: a dynamic storage allocation algorithm that satisfies a request for space with the 
first unallocated block of storage whose size is greater than or equal to the requested size. 


_ flag: one of several Booleans maintained by the CPU, including the arithmetic flags (CF, PF, AF, ZF, 
SF, OF), the control flags (TF, IF, pa} and the nested task flag (NT). 


flag word: a 16-bit register of the 80286 that contains the arithmetic flags, the control flags, the nested 
task flag, and the IOPL. The processor saves the flag word in the TSS with each task switch and loads 
the flag word from the TSS of the next task, thereby enabling each task to use the flags without 
interference from other tasks. 


fragmentation: a condition resulting from some dynamic storage- allocation alsonums, in thick 
unallocated storage is dispersed in many small areas. 3 : 


gate: a gate descriptor. 

gate descriptor: a descriptor that defines a protected entry point to an executable segment or task. 
GDT register: a register of the 80286 that contains the base address and limit of the GDT. 

global descriptor table (GDT): the descriptor table that contains descriptors that can be used by every 


task in the system. There is only one GDT per processor. 
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handler table: a table of selectors to call gates that identify the procedures for servicing asynchronous 
events such as interrupts or software signals. A handler table is used by an operating system’s interrupt. 
distributor and signalling primitives. 


I bit: a Boolean in the error code which, when set, indicates that index portion of the error code points 
to an entry in the IDT. 


iAPX 286 Binder: an iAPX 286 program development utility used to link modules, combine segments, 
and create a single-task, loadable output module. 


iAPX 286 System Builder: the configuration utility for iAPX 286 protected-mode systems. 
IDT register: an 80286 register that stores the base address and limit of the IDT. 
index: the field of a selector that identifies a slot in a descriptor table. 


indirect I/O: a style of I/O interface in which I/O operations are executed by an independent proces- 
sor, not by the CPU. 


interrupt: 1) the electrical or logical signal that an event has occurred; 2) the mechanism by aie a 
computer system responds quickly to events that occur at unpredictable times. 


interrupt controller: a device (such as Intel’s 8259A Programmable Interrupt Controller) that assists 
the CPU in responding to multiple external interrupt signals by performing such functions as detection, 
priority resolution, and identification. 


interrupt descriptor table (IDT): a descriptor table that contains gates to the handler procedures or 
handler tasks for interrupts ne traps. The IDT may contain only interrupt gates, trap gates, and task 
gates. 


interrupt distributor: an operating-system interrupt procedure that transfers control to a task-defined 
procedure for servicing the interrupt. 


interrupt-enable flag (IF): a control flag of the 80286 that determines whether the processor responds 
to external interrupt signals presented at the processor’s INTR pin. 


interrupt gate: a gate that identifies the entry point of a procedure for handling an interrupt. When an 
interrupt transfers control through an interrupt gate, the processor resets the interrupt-enable flag. 
Interrupt gates are valid only in the IDT. 


interrupt handler: a procedure or task that is invoked by an interrupt. 


interrupt latency: the time from the occurrence of an miemnupt signal to the execution of the first 
instruction of an interrupt handler. 


interrupt procedure: an interrupt handler that is identified by an interrupt gate or trap gate. An inter- 
rupt procedure runs in the interrupted task. 


interrupt task: an interrupt handler that is identified by a task gate and runs as a task peparate from 
the interrupted task. 7 . 


interrupt vectoring: the mapping from an interrupt source to the interrupt handler. In the iAPX 286 
architecture, the 8259A and the IDT are components of the interrupt vectoring process. 
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intersegment reference: a reference to a location in a segment other than the segment containing the 
reference. 


intrasegment reference: a reference to a location 1 in the same segment as the segment contaune. the 
reference. | 7 


interlevel reference: an intersegment reference to a segment that has a different privilege ve than 
that of the segment containing the reference. 


intertask transfer: a transfer of control flow to a task other that the current task. 

I/O-mapped I/O: a style of I/O interface in which I/O devices respond to addresses in an address 
space that is distinct from the memory address space. Special I/O instructions (IN, INS, OUT, OUTS) 
trigger 1/O operations. The 80286 uses the M/IO pin to distinguish memory addresses from I/O 
addresses. 

I/O privilege level (IOPL): a two-bit item in the flag register of the 80286 that controls the current 
task’s right to execute the I/O-related instructions IN, INS, OUT, OUTS, CLI, STI, LOCK. A proce- 
dure may not execute any of these instructions if CPL>IOPL. 


I/O subsystem: the portion of an operating system that deals with filing and I /O. 


IP (instruction pointer): an 80286 register that contains the offset of ne instruction to executed 
within the current code segment. 


kernel: that portion of an operating system that implements the most primitive of its functions. | 
LDT register: an 80286 register that stores the selector, base address, and limit of the current LDT. : 
limit: the field of a descriptor that defines the offset of the last byte of the segment. | | 
linkable module: an object module created by iAPX 286 translators, by the Binder, or by the Builder 
that can serve as input to either the Builder or the Binder. A linkable module requires further process- 


ing before it can be executed. 


linking: the process of combining segments from one or more input modules and resolving references 
between modules. The Binder provides linking services for iAPX 286 program development. 


loadable module: an executable object module (usually created by the Builder or the Binder) that has 
a format suitable for processing by a loader running under control of an operating system. e 


loader: the task or procedures of an operating system that places an object module in RAM and prepares 
it for execution by the operating system and the processor. 


load-time: at the time a task is loaded. 


local descriptor table (LDT): the descriptor table that contains descriptors that are (generally) private 
to a given task. Each task may have an LDT. A task can use only descriptors that are in its LDT or in 
the GDT. The LDT protects tasks from one another. 


logical segment: the representation of a segment used by translators and program development utilities 
prior to the time when the segment is actually placed in physical memory. 
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machine status word (MSW): an 80286 register that includes the TS, EM, MP, and PE poolean®: 
These items are global to the system and are not a part of the task state. 


mailbox: a software mechanism for sending messages between tasks. The mechanism consists of two 
queues: one a queue of undelivered messages, the other a queue of tasks waiting for messages. Messages 
are delivered in FIFO order. 


memory management: the set of operating system functions that Seal with fie Gyeeenon of RAM to 
tasks. A 25 


memory-mapped I/O: a style of I/O interface in which I/O devices respond to specific addresses in 
the memory address space. I/O operations are triggered by standard instructions that read from, and 
write to, memory locations. - 

message: a unit of intertask communication. 


module: a compilation unit or a combination of compilation units. 


MP (math present) flag: a Boolean in the MSW that indicates whether a processor extension (such as 
the 80287 Numerics Processor Extension) is present. 


mutual exclusion: preventing two critical sections from executing concurrently. 
multiprocessing: using more than one CPU to execute a multitasking system. 


multitasking: the capability to support more than one task either simultaneously (by using more than 
one CPU) or virtually simultaneously (by multiplexing one CPU among several tks) 


nested task (NT) flag: a Boolean in the flag word that indicates the existence of a back link field in 
the TSS to a previous TSS. 


non-maskable interrupt (NMI): an external interrupt presented to the NMI pin of the 80286 that the 
processor does not ignore, even when IF is reset. 


not-present segment: a segment whose descriptor has the present bit reset. In a virtual-memory system, 
this condition normally indicates that the segment has been evicted from RAM to maxe space for other 
segments. 


nucleus: see kernel. 
nullify: assign a null value to. 


numerics processor extension (NPX): the 80287 processor which cooperates with the 80286 CPU to 
extend its processing power in mathematical applications. 


object module format (OME): a standard for the structure of object code files. 


OF (overflow) flag: an arithmetic flag that indicates when a signed operation produces a positive number 
that is too large or a negative number that is too small to fit in the destination operand. 


offset: the address of a location within a segment, expressed as a quantity to be added to the base 
address of the segment. 
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outward call: the:attempt to call a eproceaure! in anon segment whose DPL | is numerically greater 
than CPL. 7 | | 


parallel table:. a table whose entries have a one-to-one correspondence with the entries of a Bescriplar 
table, used to associate additional information with each descriptor. | _ 


parallelism: concurrent execution of two or more tasks or devices. 


varaieler validation: specie the sen bilies of parameters pagead Between enced at different 
usgey levels | to Preven protection violations or to detect eieuen conditions. 


PE bit: a Boolean i in the MSW. that jridivates ether the 80286 j is running i in real-address made, or in 
protected, virtual-address mode. 


Petri net graph: a notation for visualizing Petri nets. Petri nets are a mathematical tool for modeling 
systems, first proposed by Dr. Carl Adam Petri in 1962. 


physical address: a 24-bit address, sich as aha used as a base address, capable of encompassing | the 
entire address space of the 80286. . | | 


physical segment: a segment as agen by the processor, to be distinguished from “logical segment.” 
PIC: programmable interrupt controller. See interrupt controller. 


pipes: a mechanism for intertask communication used in the UNIX operating system. Each task views 
a communication channel as a file and uses READ and WRITE operations to receive and send messages. 


placement policy: the algorithm for determining where in RAM to locate a segment. 


pointer: an item that specifies a memory location. A full or long pointer includes a selector, which 
indirectly chooses a segment base address, and an offset value, which points to a specific address within 
that segment. An offset by itself is called a short pointer. 


preemption: a dispatching process in which the operating system switches to another task even though 
the current task has not requested any function that would cause it to wait. The operating system may 
preempt one task i in order to give other tasks a share of CPU attention. 


prefix: one of several instruction codes that ere the function or the environment of the following 
instruction. iAPX 286 prefixes include the LOCK prefix, repeat prefixes, Segment-overide prefixes, 
and the ESCAPE prefix. 


present bit: a Boolean in a segment descriptor that indicates whether the segment is actuallly present 
in RAM. In a virtual-memory system the Seetnent may have ee evicted Om RAM to create spec 
for another segment. 3 , os 

primitive: one of the operating-system operations made accessible to applications by some explicit 
mechanism. In the iAPX 286 architecture, primitives are typically Broccuuss with call gates in the 
GDT or LDTs. 

privilege: the right to access certain portions of memory or to execute certain processor instructions. 
privilege level (PL): a measure. of privilege. In the iAPX 286. architecture, privilege is measured by 


integers in the range 0-3, where 0 is the most privileged and 3 the least. 
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privileged instruction: an instruction that can be executed only by a procedure running at privilege 
level 0. Privileged instructions include CLTS, HLT, LGDT, LIDT, LLDT, LMSW, and LTR. __ 


processor extension: an optional, special-purpose processor (such as the 80287) that runs in parallel 
with the 80286 and extends its PIDEeSSIne power. 


profiler: a procedure or F task that eollects data about seement usage. 


protected. virtual-address mode: the. ingde ‘of operaiion of the 80286 that provides. or -memory 
addressing and memory protection. | | | | as | 


protection: a mechanism that limits or prevents access to areas of memory or to instructions. .. 
public: a symbol available for intermodule reference. 

readable segment: an executable segment that can be read. It is necessary to read from an executable 
segment if that segment contains constants. A readable segment is identified by a Boolean in the access 


rights byte of its descriptor. 


read-only segment: a data segment that cannot be written to. A read-only segment is identified by a 
Boolean in the access rights byte of its descriptor. 


real-address mode: the mode of operation of the 80286 that provides greatest compatability with the 
8086, without protection and virtual memory addressing. ahs 


real memory: the physical memory, as distinguished from virtual memory. 


real-time system: a system that responds to external events in a relatively short time, as contrasted 
with a batch system. 


region: a mechanism for providing mutual exclusion among critical sections. A region is similar to a 
semaphore that has the additional properties that 1) only the task that acquires a region can nclease it, 
and ey a task: cannot be suspended while: ee a region. : 


relocation: changing the physical iseation of a segment. 


replacement policy: the algorithm that determines when to remove segments from RAM and which 
segments to remove when space is (or is likely to be) needed for another segment. 


resolving reference: see binding. 

requested privilege level (RPL): the privilege-level field of a selector. A procedure may request a 
numerically greater privilege level for use of a segment by pace: the desired Paves level 1 in the 
RPL field of the selector that identifies that segment. : 


run-time: the time a task executes. 


scheduler queue segment: a segment that contains one or more of ine task queues ee Dye a scheduler. 
Keeping a qucue in one segment may reduce the time for searching the queue. 


scheduling: sce dispatching. 
scheduling mode: one of two styles of scheduling a task: hardware- (interrupt-) scheduled mode or 


software-scheduled mode. 
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scheduling state: one of several conditions that affect the way a.task is ae yt the scheduler. A 
task may be ready to execute, executing, waiting for some event, etc. | , 


secondary storage: a slower, less expensive storage medium than RAM (for example, 3 oo 

segment: a Nonaplenensit area of contiguous ey addresses not Sheree 64K bytes. 

segment register: one of four 80286 registers that hold addressing ésformiation for the segments that 
are currently addressable by a task. The segment registers are CS (code pcemeny DS (data segment), 
ES (extra segment), and SS (stack segment). | 


selector: an item that identifies a descriptor by the location of the descriptor in a descriptor table. 


semaphore: a synchronization mechanism that communicates the occurrence of an event between two 
(or more) tasks via a shared memory location. 


send privilege level (SPL): a software-implemented measure of the right to send or delete a segment. 
shadow task: a duplicate task used to enable the operating system to perform an outward call. 


signal: a mechanism for permitting one task to communicate the occurence of an event to another task 
that is not waiting for the event to occur. 


single step: a mode of execution that permits intervention between each instruction; used primarily as 
a debugging aid. | 


slot: an entry in a descriptor table. — 


SS (stack pepment) register: the segment register that provides addressability to the current stack 
segment. 


stack segment: a 1 segment used by the processor to. hold return sddvences dynamic data, temporary 
data, and parameters. For greatest protection, each privilege level of a task may have its own stack. 
Stack segments usually expand downward. 


static system: an application in which the mix of tasks does not change over time. 


subsystem: in PL/M-286, a collection of tightly-coupled, isnieally: -related modules that obey the same 
model of segmentation. — . 


swap Space: the secondary storage area used to contain segments that have been removed from RAM. 


swapping: in a virtual-memory system, the process of moving segments between RAM and secondary 
storage. 


swapping manager: a procedure or task responsible for swapping. 

synchronization: imposition of an order on die se uence of certain seis 

system segment: a segment containing a descriptor table or task state. 

table indicator (TI): a Boolean in a selector that identifies the descriptor table to which the selector 


refers. 


Glossary-10 121960-001 


intel | GLOSSARY 


task: a single thread of execution that has an associated processor state. 
task database: the collection of information about a task that the operating system needs to store. 


task information block: a segment or part or a segment used by the operating system to contain all or 
part of a task database. 


task gate: a gate that identifies a TSS. A control transfer through a task gate causes a task switch. 
task register: an 80286 register that points to the TSS of the currently active task. 

task state segment (TSS): a segment used by the processor to store the contents of the task-variable 
registers, the stack-segment selectors and pointers for the three most privileged levels, the selector for 
the task’s local descriptor table, and a back link that may point to another task in a chain of nested 


task invocations. 


TF (single step flag): a Boolean in the flag word that, when set, indicates that the processor should 
cause a trap after each instruction. Typically, TF is used to facilitate debugging. 


thrashing: in a virtual memory system, a condition in which excessive swapping seriously degrades 
performance of all tasks. 


time-sharing system: a multi-user, multitasking system in which processors are multiplexed among 
users. 


time slice: the time interval for which the CPU is allocated to a task. 

translator: an assembler or compiler. 

trap: an interrupt due to an exception condition. 

trap gate: a gate that identifies the procedure to handle a trap. An interrupt through a trap gate differs 
from an interrupt through an interrupt gate in that, with a trap gate, interrupts are not disabled upon 


entry into the procedure. Trap gates are valid only in the IDT. 


Trojan horse: a type of protection violation in which a procedure passes a selector that it has no right 
to use to a more privileged procedure that does have the right to use it. 


trusted instruction: one of a set of I/O-related instructions that cannot be executed unless CPL is less 
than or equal to IOPL. The trusted instructions are CLI, STI, IN, INS, OUT, OUTS, and LOCK. 


type code: a value in a descriptor that specifies the intended use of a segment. The processor interprets 
the type code to ensure that segments are used only as intended. 


type extension code: a software extension to the type code concept that includes usages recognized by 
the operating system. 


UDI (Universal Development Interface): an Intel standard for interfaces to operating-system services. 
usage privilege level (UPL): a software-defined measure of the right to use an operating-system object. 


vectoring: see interrupt vectoring. 
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virtual address: an address that consists of a selector and an offset value. The selector chooses a 
descriptor for a segment; the offset provides an index into the selected segment. 


virtual address space: The set of all possible virtual addresses that a task can access, as defined by the 
GDT and the task’s LDT. The maximum possible virtual address space for one task is one gigabyte. | 


virtual memory: a style of memory management that permits the virtual address space to exceed the 
physical address space of RAM. With the help of processor features, the operating system simulates 
the virtual address space by using secondary storage to hold the overflow from RAM. 


word count: a field of a gate descriptor that specifies the number of words of parameters to be copied 
from the calling procedure’s stack to the stack of the called procedure. 


writable segment: a data segment that can be written to. A writable segment is identified by a Boolean 
in its descriptor. 


XOS (Example Operating System): an imaginary operating system, portions of which are used in this 
book asexamples. Ss 7 : 3 
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2-18 thru 2-20, 2-22, 3-1, 4-4, 5-7, 6-5, 11-8 


effective privilege level, 2-16 

EM (emulation mode) flag, 7-4, 7-8, 12-1 thru 
12-3 

emulation, 7-8, 12-1, 12-4 

ENABLE, 6-2 

ENTER, 7-6 

ENTRY, 11-6 

EPROM, 10-3 

ERROR/ pin, 7-8, 12-1 thru 12-3, 12-5 

error code, 7-1, 7-2, 7-5 thru 7-7, 7-9, 9-2, 9-3, 
12-5 
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ES register, 2-17, 2-18, 2-21, 2-22, 4-12, 7-5 
thru 7-7, 9-1, 9-6, 9-7, 10-1 

ESCAPE instructions, 7-4, 12-1 thru 12-5 

_EX (external) bit, 7-2 


examples, 2-20 thru 2-26, 3-1 thru 3-9, 3-15 thru 


3-21, 4-15, 5-8, 5-9, 5-13 thru 5-16, 10-3 
thru 10-15, 11-6 thru 11-8, 11-12 thru 
11-28 
exception, 1-7, 2-8, 2-10, 2-17, 4-3, 4-7, 5-5, 6-2, 
6-4, 6-9, Chapter 7, 9-1, 11-3, 13-3, 13-5 
handler, 6-7, Chapter 7, 9-2, 9-4, 11- 3, 12-4, 
12-5 
recovery, Chapter 7, 12-3 thru 12-5 
EXECUTE, 11-9 
execute-only segment, 7-7, 13-4 
expand- -down segment, 2-5, 11-11, 13- “4 
expansion direction, 2-5, 5-3 
EXPORT, 11-6 
export module, 11-6, 11-12, 11-13 
exports list, 11-4, 11-5 | | 
extended segmentation controls, 11-4 
EXTERNAL, 3-6 


FAR, 11-4 

fault, see exception 

FINIT, 12-5 

‘first fit” algorithm, 3-1, 3-2 
flag word, 4-2 thru 4-4, 6-2, 6-4, 8-1, 8-2, 10-1 
FNINIT, 12-2, 12-5 

FORK, 11-9 

fragmentation, 3-1, 3-2, 9- 6 
FRSTOR, 12-4 

FSAVE, 12-4, 12-5 
FSETPM, 12-2, 12-5. 


gate, 2-8, 2-11, 11-6 : 
-14, 2-15, 2-21, 3-9, 


call, 2-8, 2-10, 2-12, 2-14, 

: 4-13, 5-7, 5-12, 6-1, 6-2, 8-7, 11-3, 11-12, 
11-14 

interrupt, 2-8, 2-15, 6-2, 6-4, 6-7 

name, 11-6 

task, 2-8; 2-14, 2-15, 4-3, Fr ey 6-2, 6-4, 75) 
10-3 


trap, 2-8, 2-15, 6-2, 6-4, 6-7. 

see also descriptor, gate 
GATE, 11-6 
GDT, see global descriptor table 
GDT register, 2-15, 10-2 
general protection exception, 7-7, 8-2 
GETS$ACCESS$RIGHTS, 13-2 
GET$SEGMENTS$LIMIT, 3-6, 13-2 
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global descriptor table (GDT), 1-3, 2-12, 2-14 
thru 2-19, 2-22, 3-3, 3-4, 3-7, 3-8, 4-1, 4-3, 
4-10 thru 4-12, 5-1, 5-7, 5-10, 6-7, 7-2, 8-7, 
10-2, 10-3, 11-2, 11-4, 11-5, 11-9 thru 11-12, 
13-5 


handler table, 6-7 
hashing algorithm, 5-3 


I bit (of error code), 7-2 

iAPX 286 Binder, 1-10, 11-3, 11-5, 11-6, 11-10, 
11-11 

iAPX 286 System Builder, 1-8 thru 1-11, 2-2, 
2-4, 2-12, 2-18, 3-1, 3-6, 8-2, 10-3, een 
11-6, 11-8, 11-10, 11-11 

iAPX 386, 2-3 

identifier, 5-7, 5-10, 8-7 — 
see also interrupt identifier 

IDT, see interrupt descriptor table 

IDT register, 2-15, 6-2 

IF (interrupt-enable) flag, 4-6, 5-6, 6-2, 6-4 

index field (of selector), 2-16, 2-17, 5-3, 7-2 

INIT$REAL$MATHSUNIT, 12-2 | 

initialization 
of 80287, 12-2 
see also system initialization . 

input/output (I/O), 1-4 thru 1-7, 2-18, 4-5, 4-7, 
4-10, 5-10, Chapter 8, 9-2, 9-4, 9-8, 11-2, 
11-4,11-9 | : 

indirect, 8-3 
memory-mapped, 8- 2 


INT, 2-7, 2-10, 2-15, 4-3, 6-1, 6-2, 7-3 
INTA cycles, 2-15 
INTO, 6-1, 6-2, 7-3 
INTR pin, 6-1, 6-2, 6-6 
interrupt, 1-4, 1-7, 2-10, 2-15, 2-21, 4-3, 5-4 thru 
5-6, Chapter 6, 7-1, 7-6, 7-7, 8-4, 10-1, 10-2 
distribution, 6-7 thru 6-9 
flag, see IF 
identifier, 2-15, 6-1, 6-2 
handler, 2-15, 2-18, 4-6 
latency, see interrupt response time 
mask, 4-7, 12-4 
procedure, 4-4, 4-7, 4-11, 4-13, 6- 2, 6-4 thru 
6-7, 7-1, 12-4 
response time, 4-3, 5-5, 6-5, 12-4 
scheduled task, see scheduling 
software, 6-1 
task, 4-4, 4-7, 6-2, 6-4 thru 6-6, 7-1, 7-6, 9-4, 
12-4, 13-5 
interrupt descriptor table (IDT), 2-12, 2-15, 
2-16, 2-18, 4-3, 4-5, 4-7, 6-2, 6-4, 6-5, 6-7, 
7-2, 7-5, 10-2, 10-3, 11-11 
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“invalid TSS” exception, 7-5 thru 7-7, 9-2, 9-5 
IOPL (I/O privilege level), 4-6, 5-6, 8-1, 8-2, 
8-5 
IP register, 4-4, 6-9, 7-1, 7-3, 7-5, 7-7, 10-1, 
11-9, 12-4, 12-5 
IRET, 2-7, 2-10, 4-3, 4-4, 4-13, 6-4, 6-6, 6-7, 6-9, 
7-3, 7-5, 7-7, 8- 2, 12-5 


JMP, 2-5, 2-7, 2-9, 2-10, 4-3, 4-4, 4-13, 7-7, 
10-1, 10-3. 


LABEL, 11-4 

LAR, 9-7, 13-2, 13-4 

LARGE, 11-4 

LDT, see local descriptor table 

LDT register, 2-14, 4-3, 7-6, 9-1 

LDT selector (of TSS), 4-1, 4-3, 6-9, 7- Ds 10-2, 

— 11-ll 

LEAVE, 7-6 © 

LGDT, 2-15 

LIDT, 2-15, 6-2 

limit field (of descriptor), 2-4, 2-5, 2-12, 2-15, 
2-16, 4-1, 5-3, 7-5 thru 7-7, 9-5, 10-1,.10-3, 
11-11, 12-4, 13-2, 13-4 

linkage, 1-10, 7-6 

LLDT, 2-14, 7-6. 

LMSW, 10-1, 12-1 

loading, see program loading 

local descriptor table (LDT), 2-5, 2-12, 2-14, 
2-16, 2-18 thru 2-20, 3-1, 4-10, 5-1 thru 5-3, 
5-10, 5-17, 6-7, 7-2, 8-7, 9-3, 9-4, 9-7, 10-2, 
10-3, 11-2, 11-4, 11-5, 11-8 thru 11-12 

not present, 9-1, 9-2 

LOCALS$TABLE, 2-14 

LOCK, 8-2 

LODTXT section, 11-11, 11-12 

logical segment, 1-1, 11-2 thru 11-5 

LSL, 9-7, 13-2, 13-4 

LTR, 4-1, 9-1 


MACHINES$STATUS, 12-1. - 
mailbox, 5-10 thru 5-12, 5-16, 5-17, 8-7, 9-3, 
9-5, 11-2, 13-1, 13-4, 13-5 

mechanisms, see policies and mechanisms 
memory management | 

real, 1-8, 1-9, 2-22, Chapter 3, 5-4, 5-12, 5-17, 

8-3, 8-5, 11-6 

virtual, 1-8, 2-2, 2-3, 2-7, 7-6, Chapter 9, 11-9 
message, 2-19, 3-9, 4-9, 5-4, 5-10, 5- 12, 5- 16 
module, 11-1 thru 11-6 

bootloadable, 11-6, 11-10 

linkable, 11-6, 11-10 

loadable, 1-10, 11-10, 11-11, 11-14 

object, 1-8, 1-9, 11-9, 11-10 | 
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MOV, 7-6 

MOVS, 7-7 

MP (math present) flag, 7-4, 12-1 thru 12-4 - 

MSW (machine status word), 7-4, 7-8, 10-1, 
12-1,12-2 | 

multiprocessor systems, 3-10 

mutual exclusion, 5-5, 5-6 


naming, 11-1 thru 11-6, 11-11, 11-12, 13-1, 13-2, 
13-4, 13-5 

NEAR, 11-4 

NMI (non-maskable interrupt), 6-1, 6-2, 10-2 

NOT PRESENT statement, 11-12 

“not present” exception, 7-5 thru 7-7, te 1, 9-3 

thru 9-8, 11-3 
see also present bit 

NT (nested task) flag, 4-2 thru 4-4, 4-7, 7-6, 9-4, 
11-10 

Numerics Processor oxtemion (NPX), 
see 80287 


OBJECT, 11-6 

object module format (OMF), 11-8, 11- 10, 
~  LI-11 

OF (overflow) flag, 7-3 

OUT, 8-2 

OUTS, 7-7, 8-2 

outward call, 6-8 

overflow exception, 7-3 


paged architecture, 9-6 
parallel table, 5-3, 13-1 
parallelism, 1-4; 8-4, 8-7 
PE (protection enable) flag, 10- 1 
Petri net graph, 8-4, 8-5 > 
physical address, 1-8, 1-9, 2-4, (3-2 thru 3-4, 
11-10 
physical segment, 1-1, 1-2, 2-12, 2-15, 11-1 thru 
11-3 
PIC, see 8259A Programmable Interrupt | 
Controller 
pipes, 5-17 
PL/M-286, 2-14 thru 2-16, 2-21, 2-22, 3-3, 3-6, 
— 4-1, 4-3, 4-13, 6-2, 11-4, 11-6, 12-2, 12-4, 
13-2 
pointer parameters, see selector abraineiers 
policies and mechanisms 
scheduling, 4-9, 4-10. 
virtual memory management, 9- i; 9-6 
POP, 7-6 
POPA, 7-7 
POPF, 8-2 
preemption, 4-5, 4-7, 4-9, 4-10, 4-13 
prefix, 7-1 
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present bit, 2-2, 2-3, 2-9, 5-3, 75, 7-6, ae edae 
9-5, 11-12 

primitives, 11-3,.11-4, 11-6, 11-12, 11- 14, 134 

priority, 2-19, 4-6, 4-7, 4-9, 4-10, 6-6, 6-7 

privilege level, 1-3, 1-4, 1-8, 2-6, 2-7. thru 2-11, 


2-15, 2-18, 2-20, 2-21, 3-8, 3-9, 4-1, 4-2, 4-9, 
4-12, 4-13, 5-2, 5-7, 5-10, 5-12, 6-2, 6-3, 6-5, 


6-8, 8-2, 8-3, 8-7, 9-3, 9-7, 11-2, 11-6, 11-9, 
41-10, 12-2, 12-4, 13-1, 13-2, 13-4, 13-5 
PROC, 11-4 
“processor extension error’ exception: 7-8, 12-5 
“processor extension not available” sexcepuon, ! 
7-4, 12-3, 12-4» ees 
“processor extension segment overrun” 
exception, 7-5, 12-4, 12-5 
profiling, 9-7, 9-8 
program loading, 1-8, 1-10, 2. 3, 2- 4, 3- ay 6-5, 
Chapter 11 
bootstrap, 1-9, 11-10 © 
protected, virtual-address mode, 10- l, 10- 2, 12- 2 
protection, 1-3 thru 1-5, 1-9, Chapter 2, 3-1, 3-7, 
4-3, 4-4, 4-6, 5-1, 5-4, 5-7, 5-10, 6-2, 63. 
6-5, 6-6, 7-3, 8-1 thru 8-4, 8-7, cmpee ke 
violation, 6-4, 6-9, 7-7 
PUBLIC, 3-2, 3-6, 3-8, 3-9, 10-3, 11-3, 11-6 
PUSH, 7-6 
PUSHA, 7-7 


RCL, RCR, 7-8 

readable segment, 2-7 

read-only segment, 7-7 - 

real address mode, 10-1, 10-2 

real memory management, see memory — 
management, real . : 

recovery, see exceptions 

region, 5-10, 9-4,9-5° 

REP, REPE, REPNE, 7-7 

requested privilege level (RPL), 2-11,:2- 16, ede 
13-2 thru 13-4 

RESERVE, 3-6, 11-6 © 

reserved word (of ieceapioes 2-3, 2- 20. 

RESET, 10-1, 10-3 

RESTORESGLOBALSTABLE, 2-15 — 

RESTORESINTERRUPTSTABLE, 2-15 

RESTORESREAL$STATUS, 12-4 | 

return pointer, 6-2, Chapter 7, 12-4, 13-3 

return link, see return pointer | 

return address, see return pointer © 

relocation (of segment), 2-4, 2-20, 5-2; . 3, eS 12, 
8-3 

RET, 2-7, 2-9, 2-10, 4-3, 11-5 

RETURN, 11-5 

ROM, 10-1 a 

RPL, see requested ariileds level 


SAVE$GLOBALSTABLE, 2-15 
SAVESINTERRUPTSTABLE, 2-15°0 0 | 
SAVESREALSSTATUS, . | 


SBB,.7-8 | 


SCAS, 7-7 
scheduling, 2-19, 4-11, 5- 12, 9- 5 
hardware, see scheduling, interrupt | 
interrupt, 4-6, 4-7, 4-9, 6-1, 6-5, 6-6, 8-7 
queues, 4-12, 4-13, 9-4,.11-10, 11-14 
software, 4-7, 4-9, 6-1, 6-5, 6-6, 7-6 
state, 4-5 thru 4-7, 4-10 
SEGMENT, 11-4, 11-6 as 
segment, see logical segment, physical segment 
segment limit, see limit field _ | 
segmented architecture, 9-6 
SOME NSE OpLr: a ee 
~SEGMENTSWRITABLE, 13-2.° ~ 
selector, 2-1, 2-2, 2-8, 2-9, 2-15, 2-16, 3-6, Al, 
4-3, 5-7, 7-6, 7-7, 11-12, 13-1 — 
parameters, 2-16, 13- 1 thru 13- 4 
null, 2-15, 2-17, 7-7 
SELECTORS$OF, 3-6 — 
semaphore, 5-6, 5-7,. 5-10, 5-16, 9-4, 95, 11-2, 
12-4, 13-1, 13-4, 13-5 - : 
send privilege level (SPL), 13- 5. 
SGDT, 2-15 
shadow task, 6-8, 6-9 
sharing (of segments), 2-14, 2- 15, 2- 19, 2 20, 
2-22, 4-4, rea 8-7, 9-5, ae “2, Ad -4, 
13-1, 13-4, 13-5 | 


| shutdows: 7-5, 10-2 


SI register, 7-7. 

SIDT, 2-15, 6-2 | 

signal, 4-5, 5-7, 5-10, Ghanicces 

single-step flag (TF), 6-2, 7-3 

SLDT, 2-14, 9-7. . 

slot, 2-20, 2-22, 2-26, 5-10, 11-6, rae 14, 135 

SMALL, 11-4 

SMSW, 12-1 

SP register, 4-2, 4-12, 7-6 

SPL, see send privilege level 

SS register, 4-2, 4-12, 7-3 thru 7-7, 9.2, 9.6, 
10-1 

stack, 2-5, 2-8, 3-1, 4-12, 6-2, 6-4, 7-1, 7-2, 7-6, 
7-7, 9-3, 9-4, a 102, 11-6, 11-9 thru 
11-11, 13-4. . 

initial, 4-2, 4-3, 11 6 
overflow, 7-5, 7-7: . 
exception, 7-5 thru 7-7,9-2> 

static system, 1-7, 1-9, 1-10, 2-3, 2419, 34, 44, 
6-4, 11-9 ae 

STI, 4-6, 4-7, 5-6, 6-2, 8-2 

STOS, 7-7 

STR, 4-1, 4-7, 4-11 
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subsystem, 11-4 

swapping, 5-12, 8-3, 9-2 thru 9-4, 9-8 

_ synchronization, 2-22, 3-8, 3-9, Chapter 5, 8-4, 
8-6, 12-2, 13-4, 13-5 

system initialization, 6-5, 6-6, Chapter 10 


TABLE, 11-6 
table indicator (TI), 2-16, 2-17, 7-2 
task, 1-1 | 
creation, 2-2, 2-18, 3-1, 5-12, 6-9, 11-9 
database (TDB), 4-11, 5-12, 9-4, 11-9, 11-10, 
12-3, 12-4 
management, Chapter 4 
state, 4-1, 10-2, 12-3 
switching, 2-14, 4-1, 4-3, 4-4, 4-9, 5-6, 6-2, 7-5 
thru 7-7, 8-2, 9-4, 9-5, 10-2, 11-9, 12-2 thru 
| 12-4 
TASK, 11-6 
task register (TR), 4-1, 4-2, 4-4, 9-1, 10-2 
task state segment (TSS), 2-5, 2-14, 2-18, 3-1, 
4-1 thru 4-4, 4-10 thru 4-13, 5-1, 6-2, 6-4, 
6-9, 7-1, 7-5, 7-7, 8-2, 9-1, 9-4 thru 9-7, 
10-2, 10-3, 10-5, 11-6, 11-8 thru 11-12, 
11-14 
TASKSREGISTER, 4-1 
TDB, see task database 
termination (of task), 6-9, 7-1, 7-5, 12-5 
TF, see single-step flag 
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thrashing, 9-8 
TI, see table indicator 
time slice, 4-5, 4-9 thru 4-11 
timer, see 8254 Programmable Interval Timer 
TS (task switched) flag, 7-4, 12-1 thru 12-4 
TSS, see task state segment 
type | 
field of descriptor, 2-5, 2-17, 2-18, 2-20, 2-21, 
4-3, 4-4, 6-2, 9-3, 11-10, 11-14, 13-1 
extended, 13-1, 13-2, 13-5 


UDI (Universal Development Interface), 8-1 
“undefined opcode” exception, 7-4 , 

UNIX, 11-9 

usage privilege level (UPL), 8-7, 13-4, 13-5 


vectoring, 6-1, 6-3, 7-1 

VERR, VERW, 13-2, 13-4 

virtual memory, see memory management, 
virtual - 


WAIT, 7-4, 7-8, 12-1 thru 12-5 

WAITSFORSINTERRUPT, 4-3 

word count, 2-8 

writable data segment, 2-6, 9-5, 11-10, 11-14, 
13-1, 13-4 


XOS, 11-1, 11-2, 11-4, 11-6 
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Intel Corp.° 

201 Penn Center Boulevard 
Suite 301W 

Pittsburgh 15235 

Tel: (412) 823-4970 


Q.E.D. Electronics 
300 N. York Road 
Hatboro 19040 
Tel: (215) 674-9600 


TEXAS 


Intel Corp.” 

12300 Ford Road 
Suite 380 

Datias 75234 

Tel: (214) 241-8087 
TWX: 910-860-5617 
Intel Corp.° 

7322 S.W. Freeway 
Suite 1490 
Houston 77074 

Tel: (713) 988-8086 
TWX: 910-881-2490 


Industrial Digital Systems Corp. 
§925 Sovereign 

Suite 101 

Houston 77036 

Tel: (713) 988-9421 


Intel Corp. 

313 E. Anderson Lane 
Suite 314 

Austin 78752 

Tel: (512) 454-3628 


UTAH 


intel Corp. 

268 West 400 South 
Salt Lake City 64101 
Tat: (801) 533-8086 
VIRGINIA 


Intel Corp. 

1603 Santa Rosa Road 
Suite 109 

Richmond 23288 

Tel: (804) 282-5668 


WASHINGTON 


-Intel Corp. 


110 110th Avenue N.E. 
Suite 510 

Bellevue 98004 

Tel: (206) 453-8086 
TWX: 910-443-3002 


WISCONSIN 


intel Corp. 

450 N. Sunnyslope Road 
Suite 130 

Brookfield 53005 

Tel: (414) 784-9060 


*Field Application Location 


intel 


ALABAMA 

tArrow Electronics, Inc. 
3611 Memorial Parkway So. 
Huntsville 35405 

Tel: (205) 882-2730 


tHamilton/Avnet Electronics 


4812 Commercial Drive N.W. 


Huntsvitle 35805 
Tel: (205) 837-7210 
TWX: 810-726-2162 


tPioneer/Huntsville 
1207 Putnam Drive N.W. 
Huntsville 35805 

Tel: (205) 837-9300 
TWX: 810-726-2197 


ARIZONA 


tHamilton/Avnet Electronics 
505 S. Madison Drive 
Tempe 85281 

Tel: (602) 231-5140 

TWX: 910-950-0077 


tWyle Distribution Group 
8155 N. 24th Street 
Phoenix 85021 

Tel: (602) 249-2232 
TWX: 910-951-4282 


CALIFORNIA 


tArrow Electronics, Inc. 
521 Weddell Drive 
Sunnyvale 94086 

Tel: (408) 745-6600 
TWX: 910-339-9371 


_tArrow Electronics, Inc. 
19748 Dearborn Street 
Chatsworth 91311 
Tel: (213) 701-7500 
TWX: 910-493-2086 


tHamilton/Avnet Electronics 
350 McCormick Avenue 
Costa Mesa 92626 

Tel: (714) 754-6051 

TWX: 910-595-1928 


tHamilton/Avnet Electronics 
19515 So. Vermont Avenue 
Torrance 90502 

Tel: (213) 615-3909 

TWX: 910-349-6263 


tHamilton/Avnet Electronics 
1175 Bordeaux Drive 
Sunnyvale 94086 

Tal: (408) 743-3300 

TWX: 910-339-9332 


tHamilton/Avnet Electronics 
4545 Viewridge Avenue 

San Diego 92123 

Tel: (714) 641-4109 

TWX: 910-595-2638 


tHamilton/Avnet Electronics 


10912 W. Washington Boulevard 


Culver City 90230 
Tel: (213) 558-2458 
TWX: 910-340-6364 


tHamilton/Avnet Electronics 
21050 Erwin Street 
Woodland Hills 91367 

Tel: (213) 883-0000 

TWX: 910-494-2207 


tHamilton Electro Sales 
3170 Puliman Street 
Costa Mesa 92626 

Tel: (714) 641-4109 
TWX: 910-595-2638 


t+tHamiton/Avnet Electronics 
4103 Northgate Boulevard 
Sacramento 95834 

Tal: (916) 920-3150 


Kieruiff Electronics, Inc. 
3969 E. Bayshore Road 
Palo Alto 94303 

Tel: (415) 968-6292 
TWX: 910-379-6430 


Kierulff Electronics, Inc. 
14101 Franklin Avenue 
Tustin 92680 

Tel: (714) 731-5711 
TWX: 910-595-2599 


Kierulff Electronics, Inc. 
2585 Commerce Way 
Los Angeles 90040 

Tel: (213) 725-0325 
TWX: 910-580-3666 


tWyle Distribution Group 
124 Maryland Street 

El Segundo 90245 

Tel: (213) 322-8100 

TWX: 910-348-7140 or 7111 


tWyle Distribution Group 
9525 Chesapeake Drive 
San Diego 92123 

Tel: (714) 565-9171 

TWX: 910-335-1590 


tWyle Distribution Group 
3000 Bowers Avenue 
Santa Clara 95051 

Tel: (408) 727-2500 


TWX: 910-338-0451 or 0451/0 


tWyle Distribution Group 
17872 Cowan Avenue 
Irvine 92714 

Tal: (714) 641-1600 

TWX: 910-595-1572 


U.S. DISTRIBUTORS 


COLORADO 


tWyle Distribution Group 
451 E. 124th Avenue 
Thornton 80241 

Tel: (303) 457-9953 
TWX: 910-936-0770 


tHamilton/Avnet Electronics 
8765 E. Orchard Road 
Suite 708 

Englewood 80111 

Tel: (303) 740-1017 

TWX: 910-935-0787 


CONNECTICUT 


tArrow Electonics, inc. 
12 Beaumont Road 
Wallingford 06492 

Tel: (203) 265-7741 
TWX: 710-220-1684 


> thHamilton/Avnet Electronics 


Commerce Industrial Park 
Commerce Drive 

Danbury 06810 

Tel: (203) 797-2800 

TWX: 710-456-9974 


tHarvey Electronics 
112 Main Street 
Norwalk 06851 
Tel: (203) 853-1515 
TWX: 710-468-3373 


FLORIDA 


tArrow Electronics, Inc. 
1001 N.W. 62nd Street 
Suite 108 

Ft. Lauderdale 33309 
Tel: (305) 776-7790 
TWX: 510-955-9456 


+Arrow Electronics, Inc. 
50 Woodiake Drive W. 
Bidg. B 

Paim Bay 32905 

Tal: (305) 725-1480 
TWX: 510-959-6337 


tHamiiton/Avnet Electronics 
6801 N.W. 15th Way 

Ft. Lauderdale 33309 

Tel: (305) 971-2900 

TWX: 510-956-3097 


tHamilton/Avnet Electronics 
3197 Tech. Drive North 

St. Petersburg 33702 

Tel: (813) 576-3930 

TWX: 810-863-0374 


tPioneer/Orlando 

6220 S. Orange Blossom Trail 
Suite 412 

Orlando 32809 

Tel: (305) 859-3600 


. TWX: 810-850-0177 


tPioneer/Ft. Lauderdale 
1500 62nd Street N.W. 
Suite 506 

Ft. Lauderdale 33309 
Tel: (305) 771-7520 
TWX: 510-955-9653 


.GEORGIA 


tArrow Electronics, inc. 
2979 Pacific Drive 
Norcross 30071 

Tel: (404) 449-8252 
TWX: 810-766-0439 


tHamilton/Avnet Electronics 
§825 D. Peachtree Corners 
Norcross 30092 

Tei: (404) 447-7500 

TWX: 810-766-0432 


t¢Pioneer/Georgia 

5835B Peachtree Corners E 
Norcross 30092 

Tel: (404) 448-1711 

TWX: 810-766-4515 


ILLINOIS 


tArrow Electronics, Inc. 
2000 E. Alonquin Street 
Schaumberg 60195 
Tel: (312) 397-3440 
TWX: 910-291-3544 


tHamilton/Avnet Electronics 
1130 Thorndale Avenue 


' Bensenville 60106 


Tel: (312) 860-7780 
TWX: 910-227-0060 


tPioneer/Chicago 

1551 Carmen Drive 

Elk Grove Village 60007 
Tel: (312) 437-9680 
TWX: 910-262-1182 


INDIANA 


tArrow Electronics. inc. 
2718 Rand Road 
Indianapolis 46241 
(317) 243-9353 

TWX: 810-341-3119 


tHamitton/Avnet Electronics 
485 Gradie Orive 

Carmel 46032 

Tel: (317) 644-9333 

TWX: 810-260-3966 
+Pioneer/Indiana 

6408 Castieplace Drive 
indianapolis 46250 

Tel: (317) 849-7300 

TWX: 810-260-1794 


KANSAS 


tHamilton/Avnet Electronics 
9219 Quivera Road 
Overland Park 66215 

Tel: (913) 888-8900 

TWX: 910-743-0005 


. MARYLAND 


tHamilton/Avnet Electronics 
6822 Oak Hall Lane 
Columbia 21045 

Tel: (301) 995-3500 

TWX: 710-862-1861 


’ {Mesa Technology Corporation 


16021 Industrial Drive 
Gaithersburg 20877 


Tel: (301) 948-4350 


TWX: 710-828-9702 


tPioneer 

9100 Gaither Road 
Gaithersburg 20877 
Tel: (301) 948-0710 
TWX: 710-828-0545 


MASSACHUSETTS 


tHamilton/Avnet Electronics 
50 Tower Office Park 
Woburn 01801 

Tel: (617) 935-9700 

TWX: 710-393-0382 


tArrow Electronics, tnc. 
1 Arrow Drive 


. Woburn 01801 


Tel: (617) 933-8130 


- TWX: 710-393-6770 
. tHarvey/Boston 


44 Hartwell Avenue 
Lexington 02173 

Tel: (617) 863-1200 
TWX: 710-326-6617 


MICHIGAN 


tArrow Electronics, Inc. 
3810 Versity Drive 
‘Ann Arbor 48104 


_ Tek: (313) 971-8220 


TWX: 810-223-6020° 


tPioneer/Michigan 
_ 13485 Stamford 

Livonia 48150 

Tel: (313) 525-1800 

TWX: 810-242-3271 


tHamilton/Avnet Electronics 
32487 Schoolcraft Road 
Livonia 48150 

Tel: (313) 522-4700 

TWX: 810-242-8775 


tHamilton/Avnet Electronics 


"2215 29th Street S.E. 


Space A5 

Grand Rapids, 49508 
Tel: (616) 243-8805 
TWX: 810-273-6921 


MINNESOTA 


tArrow Electronics, Inc. 
5230 W. 73rd Street 
Edina 55435 

Tel: (612) 830-1800 
TWX: 910-576-3125 


tHamilton/Avnet Electronics 
10300 Bren Road East 
Minnetonka 55343 

Tel: (612) 932-0600 

TWX: (910) 576-2720 
Pioneer/Twin Cities 

10203 Bren Road East 
Minnetonka 55343 

Tel: (612) 935-5444 

TWX: 910-576-2738 


MISSOURI 


tArrow Electronics, Inc. 
2380 Schuetz 

St. Louis 63141 

Tel: (314) 567-6888 
TWX: 910-764-6600 


tHamitton/Avnet Electronics 
13743 Shoreline Court 
Earth City 63045 

Tel: (314) 344-1200 

TWX: 910-762-0684 


tArrow Electronics, Inc. 
1 Perimeter Road 
Manchester 03103 

Tel: (603) 668-6968 
TWX: 710-220-1684 


NEW JERSEY 


tArrow Electronics, inc. 
Pleasant Valley Avenue 
Moorestown 06057 
Tel: (215) 9286-1800 
TWX: 710-897-0629 


Arrow Electronics, inc. 
285 Midland Avenue 
Saddle Brook 07662 
Tel: (201) 797-5800 
TWX: 710-998-2206 


+Arrow Electronics, Inc. 
2 Industrial Road 
Fairtield 07006 

Tel: (201) 575-5300 
TWX: 710-998-2206 
tHamiltton/Avnet Electronics 
1 Keystone Avenue 
Bidg. 36 

Cherry Hill 08003 

Tel: (609) 424-0100 
TWX: 710-940-0262 
tHarvey Electronics 
45 Route 46 

Pinebrook 07058 

Tel: (201) 575-3510 
TWX: 710-734-4382 


{MT Systems Sates 
383 Route 46 W 
Fairfield 07006 

Tel: (201) 227-5552 


NEW MEXICO 


' +Alliance Electronics Inc. 


11030 Cochiti S.E. 
Albuquerque 87123 


_ Tet: (505) 292-3360 


TWX: 910-989-1151 


tHamilton/Avnet Electronics 
, 2524 Baylor Drive S.E. 

Albuquerque 87106 

Tel: (505) 765-1500 

TWX: 910-989-0614 


NEW YORK 


tArrow Electronics, inc. 
900 Broad Hollow Road 
Farmingdale 11735 
Tel: (516) 694-6800 
TWX: 510-224-6126 
+Arrow Electronics, Inc. 


_ 3000 South Winton Road 
Rochester 14623 


Tel: (716) 275-0300 


TWX; 510-253-4766 


tArrow Electronics, Inc. 
7705 Maltage Drive 
Liverpool 13088 

Tal: (315) 652-1000 
TWX: 710-545-0230 


tArrow Electronics, Inc. 
20 Oser Avenue 
Hauppauge 11788 

Tel: (516) 231-1000 
TWX: 510-227-6623 


tHamilton/Avnet Electronics 
333 Metro Park 

Rochester 14623 

Tel: (716) 475-9130 

TWX: 510-253-5470 


tHamitton/Avnet Electronics 
16 Corporate Circle 

E. Syracuse 13057 

Tel: (315) 437-2641 

TWX: 710-541-1560 


tHamilton/Avnet Electronics 
5 Hub Drive 

Melville, Long Island 11747 
Tel: (516) 454-6000 

TWX: 510-224-6166 
tHarvey Electronics 

P.O. Box 1208 

Binghamton 13902 

Tel: (607) 748-8211 

TWX: 510-252-0893 


¢Microcomputer System Technical Demonstrator Centers 


NEW YORK (Cont.) 


tHarvey Electronics 

60 Crossways Park West 
Woodbury, Long Island 11797 
Tel: (516) 921-8700 

TWX: 510-221-2184 


tHarvey/Rochester 
840 Fairport Park 
Fairport 14450 

Tel: (716) 381-7070 
TWX: 510-253-7001 


tMTI Systems Sales 
38 Harbor Park Drive 
Port Washington 11050 
Tel: (516) 621-6200 
TWX: 510-223-0846 


NORTH CAROLINA 


tArrow Electronics, Inc. 
938 Burke Street 
Winston-Salem 27101 
Tel: (919) 725-8711 
TWX: 510-931-3169 


tArrow Electronics, Inc. 
3117 Poplarwood Court 
Suite 123 

Raleign 27265 

Tel: (919) 876-3132 
TWX: 510-928-1856 


tHamilton/Avnet Electronics 
2803 Industrial Drive 
Raleigh 27609 

Tel: (919) 829-8030 

TWX: 510-928-1836 


tPioneer/Carolina 
103 Industrial Avenue 
Greensboro 27406 
Tel: (919) 273-4441 
TWX: 510-925-1114 


OHIO 


tArrow Electronics, Inc. 
7620 McEwen Road 
Centerville 45459 

Tel: (513) 435-5563 
TWX: 810-459-1611 


tArrow Electronics, Inc. 
6238 Cochran Road 
Solon 44139 

Tel: (216) 248-3990 
TWX: 810-427-9409 


tHamilton/Avnet Electronics 
954 Senate Drive 

Dayton 45459 

Tel: (513) 433-0610 

TWX: 810-450-2531 


tHamilton/Avnet Electronics 
4588 Emery Industrial Parkway 
Warrensville Heights 44128 
Tel: (216) 831-3500 

TWX: 810-427-9452 


tPioneer/Dayton 

4433 Interpoint Boulevard 
Dayton 45424 

Tel: (513) 236-9900 

TWX: 810-459-1622 


tPioneer/Cleveland 
4800 E. 131st Street 
Cleveland 44105 
Tel: (216) 587-3600 
TWX: 810-422-2211 


OKLAHOMA 


tArrow Electronics, Inc. 
4719 S. Memorial Orivo 
Tulsa 74145 

Tel: (918) 665-7700 


U.S. 


OREGON 


tAimac Electronics Corporation 
8022 S.W. Nimbus, Bidg. 7 
Beaverton 97005 

Tel: (503) 641-9070 

TWX: 910-467-8743 


tHamilton/Avnet Electronics 
6024 S.W. Jean Road 

Bidg. C, Suite 10 

Lake Oswego 97034 

Tel: (503) 635-7848 

TWX: 910-455-8179 


PENNSYLVANIA 


tArrow Electronics, Inc. 
650 Seco Road 
Monroeville 15146 

Tel: (412) 856-7000 
tPioneer/Pittsburgh 
259 Kappa Drive 
Pittsburgh 15238 


~ Tel: (412) 782-2300 


TWX: 710-795-3122 


tPioneer/Delaware Valley 
261 Gibraiter Road 
Horsham 19044 

Tel: (215) 674-4000 

TWX: 510-665-6778 


TEXAS 


tArrow Electronics, Inc. 
13715 Gama Road 
Dallas 75234 

Tel: (214) 386-7500 
TWX: 910-860-5377 


tArrow Electronics, Inc. 
10700 Corporate Drive 
Suite 100 

Stafford 77477 

Tel: (713) 491-4100 
TWX: 910-880-4439 


tArrow Electronics, Inc. 
10125 Metropolitan 
Austin 78758 

Tel: (512) 835-4100 
TWX: 910-874-1348 


tHamilton/Avnet Electronics 
2401 Rutland 

Austin 78757 

Tel: (512) 837-8911 

TWX: 910-874-1319 


tHamilton/Avnet Electronics 
2111 W. Walnut Hill Lane 
Irving 75062 

Tel: (214) 659-4100 

TWX: 910-860-5929 


tHamilton/Avnet Electronics 
8750 West Park 

Houston 77063 

Tel: (713) 780-1771 

TWX: 910-881-5523 


tPioneer/Austin 
9901 Burnet Road 
Austin 78758 

Tel: (512) 835-4000 
TWX: 910-874-1323 


tPioneer/Dallas 
13710 Omega Road 
Dallas 75234 

Tel: (214) 386-7300 
TWX: 910-850-5563 


tPioneer/Houston 
§853 Point West Drive 
Houston 77036 

Tel: (713) 988-5555 
TWX: 910-576-2738 


DISTRIBUTORS 


UTAH 


tHamilton/Avnet Electronics 
1585 West 2100 South 

Salt Lake City 84119 

Tel: (801) 972-2800 

TWX: 910-925-4018 

tArrow Electronics, inc. 
4980 Amelia Earhart Drive 
Sait Lake City 64112 

Tel: (801) 539-1135 
WASHINGTON 


tAimac Electronics Corporation 
14360 S.E. Eastgate Way 


‘Bellevue 98007 


Tel: (206) 643-9992 
TWX: 910-444-2067 


tArrow Electronics, Inc. 
14320 N.E. 21st Street 
Bellevue 98007 

Tet: (206) 643-4800 
TWX: 910-444-2017 


tHamilton/Avnet Electronics 
14212 N.E. 21st Street 
Bellevue 98005 

Tel: (206) 453-5874 

TWX: 910-443-2469 


WISCONSIN 


tArrow Electronics, inc. 

430 W. Rausson Avenue 
Oakcreek 53154 

Tel: (414) 764-6600 

TWX: 910-262-1193 
tHamiiton/Avnet Electronics 
2975 Moorland Road 

New Berlin 53151 

Tel: (414) 784-4510 

TWX: 910-262-1182 


tMicrocomputer System Technical Demonstrator Centers 


intel 


BELGIUM 


Intel Corporation S.A. 
Parc Seny 

Rue du Moulin a Papier 51 
Boite 1 

B-1160 Brussels 

Tel: (02) 661 07 11 
TELEX: 24814 


DENMARK 


intel Denmark A/S° 
Lyngbyvej 32F 2nd Floor 
DK-2100 Copenhagen East 
Tel: (01) 18 20 00 

TELEX: 19567 


FINLAND 


. Intel Finland OY 
Hameentie 103 
SF - 00550 Helsinki 55 
Tel: 0/716 955 
TELEX: 123 332 ' 


FRANCE 


Intel Corporation, S.A.R.L.° 
5 Place de la Balance 

Silic 223 

94528 Rungis Cedex 

Tel: (01) 687 22 21 

TELEX: 270475 


Intel Corporation, S.A.R.L. 
Immeuble BBC 

4 Quai des Etroits 

69005 Lyon 

Tel: (7) 842 40 89 

TELEX: 305153 


INTEL EUROPEAN SALES OFFICES 


WEST GERMANY 


Intel Semiconductor GmbH* 
Seidistrasse 27 

D-8000 Muenchen 2 

Tel: (89) 53891 

TELEX: 05-23177 INTL D 


Intel Semiconductor GmbH* 
Mainzer Strasse 75 

D-6200 Wiesbaden 1 

Tel: (6121) 70 08 74 
TELEX: 04186183 INTW D 


Intet Semiconductor GmbH 
Brueckstrasse 61 

7012 Felibach 

West Germany 

Tel: (711) 58 00 82 

TELEX: 7254826 INTS D 


Intel Semiconductor GmbH* 
Hohenzollern Strasse 5° 
3000 Hannover 1 

Tel: (511) 34 40 81 

TELEX: 923625 INTH D 


Intel Semiconductor GmbH 
Ober-Ratherstrasse 2 
0-4000 Dusseldorf 30 

Tel: (211) 65 10 54 
TELEX: 08-58977 INTL D 


ISRAEL 


intel Semiconductor Ltd.* 
P.O. Box 1659 

Haifa 

Tel: 4/524 261 

TELEX: 46511 


ITALY 


inte! Corporation Italia Spa‘ 
Miltanofiori, Palazzo E 
20094 Assago (Milano) 

Tet: (02) 824 00 06 

TELEX: 315183 INTMIL 


‘NETHERLANDS 


Intel Semiconductor Nederland BV. 
Alexanderpoort Building 


_Marten Meesweg 93 


3068 Rotterdam 
Tel: (10) 21 33 77 


- TELEX: 22283 


NORWAY 


. Intel Norway A/S 


P.O. Box 92 
Hvamveien 4 
N-2013 
Skjetten 

Tel: (2) 742 420 
TELEX: 18018 


SWEDEN 


Intel Sweden A.B.° 
Box 20092 
Archimedesvagen 5 
S-16120 Bromma 
Tel: (08) 98 53 85 
TELEX: 12261 


SWITZERLAND 


Intel Semiconductor A.G.° 
Forchstrasse 95 

CH 8032 Zurich 

Tel: (01) 55 45 02 

TELEX: 57989 ICH CH 


UNITED KINGDOM 


Intel Corporation (U.K.) Ltd.° 
5 Hospital Street 

Nantwich, Cheshire CW5 5RE 
Tel: (0270) 626 560 

TELEX: 36620 

Intel Corporation (U.K.) Ltd.* 
Pipers Way 

Swindon, Wiltshire SN3 TRJ 
Tel: (0793) 488.388 

TELEX: 444447 INT SWN  - 


*Field Application Location 


EUROPEAN DISTRIBUTORS/REPRESENTATIVES 


AUSTRIA 


Bacher Elektronische Geraete GmbH 
Rotemuehigasse 26 

A 1120 Vienna 

Tel: (222) 83 63 96 

TELEX: 11532 BASAT A 


BELGIUM 


Ineico Belgium S.A. 
Ave. des Croix de Guerre 94 
B1120 Brussels 

Tel: (02) 216 01 60 

TELEX: 25441 


DENMARK 


MultikKomponent A/S 
Fabriksparken 31 
OK-2600 Gloskrup 
Tel: (02) 45 66 45 
TX: 33355 


Scandinavian Semiconductor 
Supply A/S 

Nannasgade 18 

OK-2200 Copenhagen 

Tei: (01) 83 50 90 

TELEX: 19037 


FINLAND 


Oy Fintronic AB 
Melkonkatu 24 A 
SF-00210 

Helsinki 21 

Tel: (0) 692 60 22 

TELEX: 124 224 Ftron SF 


FRANCE 


Jermyn S.A. 

rue Jules Ferry 35 
93170 Bagnolet 
Tel: (1) 859 04 04 
TELEX: 213810 F 


Metrologie 

La Tour d' Asnieres 

1, Avenue Laurent Cely 
92606-Asnieres 

Tel: (1) 791-44 44 
TELEX: 611 448 


Tekelec Airtronic 
Cite des Bruyeres 
Rue Carle Vernet 
F-92310 Sevres 
Tel: (01) 534 75 35 
TELEX: 204552 


WEST GERMANY 


Electronic 2000 Vertriebs A.G. 
Neumarkter Strasse 75 
D-8000 Munich 80 

Tel: (89) 43 40 61 

TELEX: 522561 EIEC D 


Jermyn GmbH 

Postfach 1180 
Schuistrasse 48 

0-6277 Bad Camberg 
Tel: (06434) 231 

TELEX: 484426 JERM OD 


Celdis Enatechnik Systems GmbH 
Schillerstrasse 14 

0-2085 Quickborn-Hamburg 

Tel: (4106) 6121 

TELEX: 213590 ENA D 


Proelectron Vertriebs GmbH 
Max Pianck Strasse 1-3 
6072 Dreieich bei Frankfurt 
Tel: (6103) 33564 

TELEX: 417983 


IRELAND 


Micro Marketing 
Glenageary Office Park 
Glenageary 

Co. Dublin 

Tel: (1) 85 62 88 
TELEX: 31584 


ISRAEL 


Eastronics Ltd. 

11 Rozanis Street 
P.O. Box 39300 
Tel Aviv 61390 
Tel: (3) 47 51 51 
TELEX: 33638 


ITALY 


Eledra 3S S.P.A. 
Viale Elvezia, 18 
| 20154 Milano 
Tel: (2) 34 97 51 
TELEX: 332332 
Intesi 

Milanfiori Pal. E/5 
20090 Assago 
Milano 

Tel: (02) 82470 
TELEX: 311351 


NETHERLANDS 


Koning & Hartman 
Koperwerf 30 

P.O. Box 43220 

2544 EN 's Gravenhage 
Tel: 31 (70) 210.101 
TELEX: 31528 


NORWAY 


Nordisk Elektronic (Norge) A/S 
Postoffice Box 122 
Smedsvingen 4 

1364 Hvalstad 

Tel: (2) 786 210 

TELEX: 16963 


PORTUGAL 

Ditram 

Componentes E Electronica LDA 
Av. Miguel Bombarda, 133 
P1000 Lisboa 

Tet: (19) 545 313 

TELEX: 14182 Brieks-P 


SPAIN 


Interface S.A. 

Ronda San Pedro 22, 3 
Barcelona 10 

Tel: (3) 301 78 51 

TWX: 51508 


ITT SESA 

Miguel Ange! 23-3 
Madrid 10 

Tel: (1) 419 54 00 
TELEX: 27707 


SWEDEN 


AB Gosta Backstrom 
Box 12009 
Alstroemergatan 22 
$-10221 Stockholm 12 
Tel: (8) 541 080 
TELEX: 10135 


Nordisk Electronik AB 
Box 27301 
Sandhamnsgatan 71 
S-10254 Stockhoim 
Tel: (8) 635 040 
TELEX: 10547 


SWITZERLAND 


industrade AG 
Gemsenstrasse 2 
Postcheck 80 - 21190 


_ CH-8021 Zurich 
“Tel: (01) 363 23 20 
TELEX: 56788 INDEL CH 


UNITED KINGDOM 


Bytech Ltd. 
Unit 57 

London Road 
Earley, Reading 
Berkshire 


Tel: (0734) 61031 


TELEX: 848215 


Comway Microsystems Ltd. 
Market Street ‘ 
UK-Bracknell, Berkshire 
Tel: 44 (344) 55333 
TELEX: 847201 

DECADE Ltd. 

100 School Road 
Tilehurst 

Reading, Serkshire 

Tel: (0734) 413127 
TELEX: 837953 


'. Jermyn Industries 


Vestry Estate 
Sevenoaks, Kent 
Tel: (0732) 450144 
TELEX: 95142 


M.E.D.L. 

East Lane Road 
North Wembley 
Middlesex HAS 7PP 
Tel: (01) 904 93 07 
TELEX: 28817 


Rapid Recall, Ltd. 

Rapid House/Denmark St 
High Wycombe 

Berks, England HP11 2ER 
Tel: (0494) 26 271 

TELEX: 837931 


YUGOSLAVIA 


H. R. Microelectronics Enterprises 
P.O. Box 5604 

San Jose, California 95150 

Tel: 408/978-8000 

TELEX: 278-559 


intel 


AUSTRALIA JAPAN 


Intel Semiconductor Pty. Ltd. intel Japan K.K. 
Spectrum Building §-6 Tokodai, Toyosato-machi 


INTEL INTERNATIONAL SALES OFFICES 


intel Japan K.K. 

2-69 Hon-cho 
Kumagaya, Saitama 360 
Tel: 0485-24-6871 


Intel Japan K.K 

1-5-1 Marunouchi 
Chiyoda-ku, Tokyo 100 
Tel: 03-201-3621/3681 


200 Pacific Highway Tsukuba-gun, Ibaraki-ken 300-26 

Level 6 Tel: 029747-8511 Intel Japan K.K.° Intel Japan K.K.* 

Crows Nest, NSW, 2089 TELEX: 03656-160 2-4-1 Terauchi 1-23-9 Shinmachi 
Australia , Intel Japan K.K. Toyonaka, Osaka 560 Setagaya-ku, Tokyo 154 


Tel: 011-61-2-436-2744 Tel: 06-863-1091 Tel: 03-426-2231/427-8845 


TELEX: 790-20097 


HONG KONG 


Intel Semiconductor Corp. 
99-105 Des Voeux Rd., Central 
18F, Unit B 

Hong Kong 

Tel: 011-852-5-499-432 
TELEX: 63869 


2-1-15 Naka-machi 
Atsugi, Kanagawa 243 
Tel: 0462-23-3511 


intel Japan K.K.° 

2-51-2 Kojima-cho 
Chofu, Tokyo 182 
Tel: 0424-88-3151 


“Field Application Location 


INTERNATIONAL DISTRIBUTORS/REPRESENTATIVES 


ARGENTINA 


VLC S.R.L. 

Sarmiento 1630 Piso 

(1042) Buenos Aires 

Tel: 35-1202/9242 

TELEX: Public Booth 9900 or 9901 


Mailing Address 

Soimex Internationa! Corporation 
15 Park Row, Room #1730 

New York, New York 10038 
(212) 406-3052 

Attn: Gaston Briones 


AUSTRALIA 


Total Electronics 
9 Harker Street 
Burwood 

Victoria 3125 

Tel: 61 3 288-4044 
TELEX: AA 31261 


Mailing Address 
Private Bag 250 
Burwood, Victoria 3125 
Australia 


Total Electronics 

#1 Johnstone Lane 
Lane Cove, N.S.W. 2066 
TELEX: 26297 


BRAZIL 


Icotron S.A, 

05110 Av. Mutinga 3650-6 Andar 
Pirituba Sao Paulo 

Tel: 261-0211 

TELEX: 1122274/ICOTBR 


CHILE 


DIN 

AV. VIC MCKENNA 204 
Casilla 6055 

Santiago 

Tel: 227 564 

TELEX: 352003 


COLOMBIA 


International Computer Machines 
Carrera 7 No. 72-34 

Apdo. Aereo 19403 

Bogota 1 

Tel: 211-7282 

TELEX: 45716 ICM CO. 


HONG KONG 


Schmidt & Co. Ltd. 

Wing on Centre, 28th Floor 
111 Connaught Road Central 
Tel: 5-455-644 

TELEX: 74766 SCHMC HX 


INDIA 


Micronic Devices 

104/109C, Nirmal Industrial Estate 
Sion (E) 

Bombay 400022 

Tel: 486-170 

TELEX: 011-71447 MDEV IN 


JAPAN 


Asahi Electronics Co. Ltd. 
KMM Bldg. Room 407 
2-14-1 Asano, Kokura 
Kita-Ku, Kitakyushu City 802 
Tel: (093) 511-6471 

TELEX: AECKY 7126-16 


Hamilton-Avnet Electronics Japan Ltd. 


YU and YOU Bldg. 1-4 Horidome-Cho 
Nihonbashi Chuo-Ku, Tokyo 103 

Tel: (03) 662-9911 

TELEX: 2523774 


Ryoyo Electric Corp. 
Konwa Bidg. 
1-12-22, Tsukiji 
Chuo-Ku, Tokyo 104 
Tel: (03) 543-7711 


Tokyo Electron Ltd. 

Shin Juku, Nomura Bldg. 
26-2 Nishi-Shin Juku-Ichome 
Shin Juku-Ku, Tokyo 160 
Tel. (03) 343-4411 

TELEX: 232-2220 LABTEL J 


KOREA 


Koram Digital 

Room 909 Woonam Bidg. 
7, 1-KA Bongre-Dong 
Chung-Ku Seoul 100 

Tel: 2-753-8123 

TELEX: K25299 KODIGIT 


NEW ZEALAND 


McLean Information Technology Ltd. 
459 Kyber Pass Road, Newmarket, ' 
P.O. Box 9464, Newmarket 
Auckland 1, New Zealand 

Tel: 501-801, 501-219, 587-037 
TELEX: NZ21570 THERMAL 


SINGAPORE 


General Engineers Corporation Pty. Ltd. 
Block 3, Units 1003-1008, 10th Floor 
P.S.A. Muiti-Storey Complex 

TELOK BLANGAH/Pasir Panjang Road 
Singapore 0511 

Tel: 271-3167 

TELEX: RS23987 GENERCO 


SOUTH AFRICA 


Electronic Building Elements, Pty. Ltd. 
P.O. Box 4609 

Hazelwood, Pretoria 0001 

Tel: 011-27-12-46-9221 or 9227 
TELEX: 3-0181 SA 


TAIWAN 


Taiwan Automation Corp.* 
3d Floor #75, Section 4 
Nanking East Road 

Taipei 

Tel: 771-0940 

TELEX: 11942 TAIAUTO 


YUGOSLAVIA 


H. R. Microelectronics Enterprises 
P.O. Box 5604 

San Jose, California 95150 

Tel: (408) 978-8000 

TELEX: 278-559 


‘Field Application Location 


CALIFORNIA 


Intel Corp. 

1350 Snorebird Way 

Mt. View 94043 

Tel: (415) 968-8086 

TWX: 910-339-9279 
910-338-0255 


Intel Corp. 

2000 E. 4th Street 
Suite 110 

Santa Ana 92705 
Tel: (714) 835-2670 
TWX: 910-595-2475 


Intel Corp. 

7670 Opportunity Road 
San Diego 92111 

Tel: (714) 268-3563 


intel Corp. 

5530 N. Corbin Avenue 
Suite 120 

Tarzana 91356 

Tel: (213) 708-0333 


COLORADO 


Intel Corp. 

650 South Cherry 
Suite 720 

Denver 80222 

Tet: (303) 321-8086 
TWX: 910-931-2289 


CONNECTICUT . 


Intel Corp. 

36 Padanaram Road 
Danbury 06810 

Tel: (203) 792-8366 


FLORIDA 


Intel Corp. 

1500 N.W. 62nd Street 
Suite 104 

Ft. Lauderdale 33309 
Tel: (305) 771-0600 
TWX: 510-956-9407 


Intel Corp. 

500 N. Maitland Avenue 
Suite 205 

Maitland 32751 

Tel: (305) 628-2393 
TWX: 810-853-9219 


Intel Corp. 

5151 Adanson Street 
Orlando 32804 

Tel: (305) 628-2393 


GEORGIA 


Intel Corp. 

3300 Holcomb Bridge Road 
Suite 225 

Norcross 30092 

Tel: (404) 449-0541 


ILLINOIS 


Intel Corp. 

- 2550 Golf Road 
Suite 815 
Rolling Meadows 60008 
Tel: (312) 981-7230 
TWX: 910-253-1825 


KANSAS 


inte! Corp. 

9393 W. 110th Street 
Suite 265 

Overland Park 66210 
Tel: (913) 642-8080 


MARYLAND 


Intel Corp. 

7257 Parkway Drive 
Hanover 21076 

Tel: (301) 796-7500 
TWX: 710-862-1944 


U.S. SERVICE OFFICES 


MASSACHUSETTS 


Intel Corp. 

27 Industrial Avenue 
Chelmsford 01824 
Tel: (617) 256-1800 
TWX: 710-343-6333 


MICHIGAN 


Intel Corp. 

26500 Northwestern Highway 
Suite 401 

Southfield 48075 

Tel: (313) 353-0920 

TWX: 810-244-4915 


MINNESOTA 


Intel Corp. 

7401 Metro Boulevard 
Suite 355 

Edina 55435 

Tel: (612) 835-6722 
TWX: 910-576-2867 


MISSOURI 


Intel Corp. 

4203 Earth City Expressway 
Suite 143 

Earth City 63045 

Tal: (314) 291-1990 


NEW JERSEY 


Intel Corp. 

385 Sylvan Avenue 
Englewood Cliffs 07632 
Tel: (201) 567-0820 
TWX: 710-991-8593 


NEW YORK 


Intel Corp. 

2255 Lyell Avenue 
Rochester 14606 
Tal: (716) 254-6120 


NORTH CAROLINA 


intel Corp. 

5600 Executive Drive 
Suite 113 

Charlotte 28212 

Tel: (704) 568-8966 


Intel Corp. 

2306 W. Meadowview Road 
Suite 206 

Greensboro 27407 

Tel: (919) 294-1541 


OHIO 


Intel Corp. 
Chagrin-Brainard Bldg. 
Suite 300 

28001 Chagrin Boulevard 
Cleveland 44122 

Tel: (216) 464-6915 

TWX: 810-427-9298 


Intel Corp. 

6500 Poe Avenue 
Dayton 45414 

Tel: (800) 325-4415 
TWX: 810-450-2528 


OKLAHOMA 


Intel Corp. 

4157 S. Harvard 
Suite 123 

Tulsa 74101 

Tel: (918) 749-8688 


OREGON 
Intel Corp. 


10700 S.W. Beaverton-Hillsdale Highway 


Suite 22 

Beaverton 97005 
Tel: (503) 641-8086 
TWX: 910-467-8741 


PENNSYLVANIA 


Intel Corp. . ; 
500 Pennsylvania Avenue 
Fort Washington 19034 
Tel: (215) 641-1000 

TWX: 510-661-2077 


Intel Corp. 

201 Penn Center Boulevard 
Suite 301 W. 

Pittsburgh 15235 

Tel: (313) 354-1540 


TEXAS 


Intel Corp. 

313 E. Anderson Lane 
Suite 314 

Austin 78752 

Tel: (512) 454-8477 
TWX: 910-874-1347 


Intel Corp. 

2925 L.B.J. Freeway 
Suite 175 

Dallas 75234 

Tel: (214) 241-2820 
TWX: 910-860-5617 


intel Corp. 

7322 S.W. Freeway 
Suite 1490 

Houston 77074 

Tel: (713) 988-8088 
TWX: 910-881-2490 


VIRGINIA 


Intel Corp. 

7700 Leesburg Pike 
Suite 412 

Falls Church 22043 
Tel: (703) 734-9707 
TWX: 710-931-0625 


WASHINGTON 


Intel Corp. 

110 110th Avenue N.E. 
Suite 510 

Bellevue 98004 

Tel: 1-800-538-0662 
TWX: 910-443-3002 


WISCONSIN 


Intel Corp. 
150 S. Sunnyslope Roa 
Suite 148 

Brookfield 53005 

Tel: (414) 784-9060 


intel ‘Intel Carporaton 
3065 Bowers Avenue 
Santa Clara, CA 95051 


Intel Corporation S.A. 
Parc Seny 

Rue du Moulin a Papier 51 
Boite 1 

B-1160 Brussels 

Belgium 


Intel Japan K.K. 

5-6 Tokodai Toyosato-machi 
Tsukuba-gun, Ibaraki-ken 300-26 
Japan 
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